According to the haxe documentation, We place some restrictions on the name/user, specifically:

• Length must be >= 3
• All characters must be one of [A-Za-z0-9_-.]

I could find no such restrictions on tags, on the site, or in the haxelib code (but I definitely could have missed it). I think we should place similar restrictions on tags as we place on user names and project names.

We need to decide:

What restrictions should we place on tag names?

I think we should use the same character restrictions everywhere. Easier for us, and easier for users, and I don't think it's too restrictive. Tags need to be at least down to 2 characters long, to support current tags like 'js' and 'cs'.

Do we want to change any of the rules for projects/user names?

• We could allow more characters (accents, other symbols. e.g. A*path or C++ proj).
• We could change the minimum length to two. This allows for the same verification for tags, projects, and user names.

When installing a library with HaxeLib GIT you get the following error:

License must be one of the following: [GPL,LGPL,BSD,Public,MIT]

However the library has the haxelib.json with MIT license.
Test with:
haxelib git poly2trihx https://github.com/nerik/poly2trihx.git

Cross posted from HaxeFoundation/haxe#1874

The error is in the Data.hx readData() function. It assumes that doc.contributors is non-null, casts to Array, and then uses it.

I don't know if "contributors" is intended to be a required field in haxelib.json as I haven't found any documentation describing what fields can be present in a haxelib.json files and which fields would be required. However, I don't think that any field should be required.

In any case, haxelib shouldn't crash even if it does want contributors to be required, it should print an error and exit if it detects a missing required field.

The restriction to only a handfull of possible Licenses is pretty bad, and forces the developer into the virability of the big GNU.

Even if I dislike the GNU-License-Package, it should be accepted as a whole and not only the current subset. In particular you are missing the Affero and Document (OK, this will probably used very seldom) flavor.

But in General I would appreciate one of the following solutions:

1. Make the license a freeform entry and add a mandatory field for an URL that shows the license. Add to haxelibs ToU that hosted Libs have to be open sourced.
2. Add the option "other" and make license-URL mandatory if used or optional any other case. Extend haxelibs ToU like in 1.
3. Allow more (or even all?) of the licenses listed in http://opensource.org/licenses/alphabetical

We'll also need to discuss any restrictions that we want to put in place for submitting, because they need to be in place for launch.

The proposed JSON format is here, though we may move out the project-admin stuff and leave only the info specific to that library and that version.

Things I think are important:

• Version number of the library
• Version number of dependencies (both libraries and haxe version)
• Reserved names. "haxe", "haxelib" and "haxedoc" seem sensible to reserve.

Other possible ones:

• Licence (do we want to limit it still? If we do, we should increase the number used)

... most of the other stuff I think should be limited is project management stuff, which we probably want to remove from the JSON anyway....

Because I think, there is much more duscussion needed than it could be done on github, I posted my proposal to the haxelang mailinglist (Thread https://groups.google.com/forum/?fromgroups#!topic/haxelang/KrYoVwRQilU) but will quote it here:

Coming from the ruby programming language and enjoying its very good library distribution service called gems, I would like to make a proposal to make haxelib much better.

As far as I can see, some of my points would make a massive overhaul of the system necessary, but I'll try to achieve at least theoretical compatibility.

As it is now, every lib needs a file haxelib.json in its root which contains some metadata. I would suggest to change the following fields:

url

The homepage or source URL of the lib.
This should be split up into homepage_url (the actual homepage of the project) and source_url (the URL to a page which explains sourcecode access or a project page on github/sourcefourge etc)

license

The license of the project, limited to a handful of OSS-licenses and Public Domain. This field should accept at least one additional value: other. When other is used, then license_url has to be given with an URL to the license, also a file /LICENSE(\..*)/ (Plain-Text readable) has to be in the package-root.

dependencies

An array of libs the lib is depending on. Perhaps this should be split up into dependencies and dev_dependencies. The first is obvious, the latter lists requirements for development/contribution, like test libs.

contributors

A list of contributors to the project, also it seems to give the mentioned users to upload the libs versions into the database and is integrated into some kind of registration process. I would propose to open registering from the webinterface and also from the command line, but by providing the commands haxelib register and haxelib login, also I would suggest to make the email address mandatory, so a contact could be established at least via haxelib webfrontend. Also I couldn't find any hints on requiring a certain version of a lib, this should be added, I would suggest ruby gems style of specifying version requirements (http://docs.rubygems.org/read/chapter/16#page74)

Also I would suggest to provide some new fields:

haxelevel

Version number of haxe the lib has to be used with. Starting with 3 for current language version. I would suggest a simple integer for the value, since I assume that there will be no breaking changes in the language itself between minor-releases.

stdlib

Version of the standard library that is used in development process. Like 3.0 or 3.1. Here I assume, that the minor number contains the version of the standardlib. If you have a higher stdlib installed, haxelib will use that lib, but if your local haxe version does not match the requirements, the last compatible version is fetched from the server AND a warning is displayed that advises you to update your haxe installation

haxelib

This one is a bit complicated, since it specifies how to read the haxelib.json:

• If haxelib.json is missing but there is an haxelib.xml, then haxelib version 2 is assumed, also it maps "haxelib test" to "haxelib local" but only if in the specified directory a haxelib.xml exists.
• If haxelib.json is present, but the haxelib field is missing, then haxelib behaves as haxelib as it is now and all my suggested changes will be ignored.
• If haxelib.json is present and haxelib field is set to 3 everything I suggested here will be applied.

This way, the same haxelib server could be used for every haxe languagelevel, without that ugly split up repo in current and legacy.

There's a magical relationship between haxe and haxelib, and the point of contact is the haxelib path x command. This allows developers the convenience of invoking the compiler with the args -lib x, and having that resolve to any number of additional arguments.

I think some extensibility here would be very powerful, something along the lines of: if haxelib doesn't find a lib, try this other (or these other) neko programs to see if they can.

Working in company with a large number of both open and proprietary libraries, managing project dependencies with haxelib can be painful. This sort of functionality would make it considerably more flexible.

Allow for a project to depend on certain a certain version of Haxe.

So that in future new installs will start on the most recent version.

Is this the intention? If the selfupdate is working reliably (which it appears to be) I think it would be a good move, rather than having to explain to first time users how to selfupdate.

haxelib is a simple system to handle dependencies but this could well be extended to support many thing (a la maven) like unit test for example (to make sure you deploy only well tested releases)

For testing, since there are many different test runners available, this can only be achieved by allowing haxelib to run plugins that then do the extra work.

This is of course not easy as it sounds but I though I suggest it.

I would prefer source plugin to which haxelib compile on the go (see https://github.com/back2dos/haxelib/issues/36)

Suggest using "sudo" if not on Windows, or give an error message otherwise.

Currently just prints

[[ /usr/lib/haxe/lib/.../something.zip ]]

which is not the most helpful to new users.

I submitted a library using this haxelib.json yesterday:

{
  "name": "hxparse",
  "url": "https://github.com/Simn/hxparse",
  "license": "BSD",
  "description": "This library provides tools for creating lexers and parsers in haxe.",
  "version": "1.0.1",
  "releasenote": "initial release",
  "contributors": ["simn"]
}

Today I wanted to push an update using the same haxelib.json (with a modified releasenote), but haxelib went on complaining "User 'simn' is not a developer of project 'hxparse'".

This is because my username for haxelib is uppercase Simn. It worked after changing contributors accordingly, but it should consistently work or fail for both initial and update submission.

If there were an RSS-feed, you could easily stay up to date and be aware of new libs added.

There should be at least a global feed which nitifies about every single lib added or updatet. An addition per tag feed would be nice but is not mandatory.

Another very cool feature would be, if you could sign up for a user account and have a private feed which informs you about changes made by watched maintainers or in watched libs, similar to the github-private-feed.

For example:
http://lib.haxe.org/p/air3

It would be nice to place a link suggesting it might be located under legacy/

Minimal test case:

test/haxelib.json:

{ "name": "test", "version": "local", "contributors": ["deltaluca"] }

zip test haxelib.json
haxelib local test.zip

test2/haxelib.json:

{ "name": "test2", "version": "local", "contributors": ["deltaluca"], "dependencies": { "test": "" } }

zip test2 haxelib.json
haxelib local test2.zip

output:

...
Done
Installing depdendency test
No such Project : test

This will be useful in general, but specifically it will make it easier to test selfupdate on a local server (or my VPS which I'll leave online) before we release something to the world.

Any recommendations for implementation? Command line arg, environment variable, ".haxelib" file, other?

For uploading new packages, it would be great to support https connections so the password isn't passed as clear text

Having many big libraries like openfl-* installed and after some updates, you lib folder may become very big.

Its possible to remove the old versions one by one, but i think that a cleanup command would be handy.

Either remove old versions of each library
haxelib cleanup openfl-natives
Or cleanup all
haxelib cleanup

Is there any doc regarding the json spec for the haxelib.json file?

I tested it with haxelib local <zip file> and the following was the minimal valid haxelib.json I got. By the way errors were not helpful, they just mentioned Invalid field access : length and Invalid field access : toString and not what fields were missing.

{
  "name":"test",
  "version":"0.0.1",
  "contributors":[]
}

Then I tested with haxelib submit and got the following minmal haxelib.json:

{
  "name":"test",
  "version":"0.0.1",
  "contributors":[],
  "license":"GPL",
  "releasenote":"testing haxelib.json spec"
}

This time when not puting "license" and "releasenote" it asked for it.
Interestingly, it considered me as a user named "null" and ask for my email. I stopped there

It would be nice if there were official doc on the spec,

• What are the mandatory field?
• What basic value are required for these mandatory fields (contributors for example should never accept an empty array, version requires a semver string, etc...)
• What are the default values for the optional field?

I need that information as I am implementing a tool that want to use an extended haxelib.json spec (a superset) and thus I need to provide the same mandatory fields and default values.

On leopard 10.5 haxelib suddenly stopped working.

JustinComputer:helloCpp justinmills$ haxelib selfupdate
haxelib is up to date
/usr/bin/haxelib: line 2: 35065 Bus error haxe -cp "/usr/lib/haxe/lib/haxelib_client/3,0,0-rc,7/" -D haxelib_client --run tools.haxelib.Main $@
JustinComputer:helloCpp justinmills$

Compiling from a fresh fork of the repo I get this error

Called from tools/WebServer.nml line 501
Called from tools/WebServer.nml line 473
Called from tools/haxelib/SiteDb.hx line 72
Exception : Neko_error(Invalid call)

I'm running Haxe r6388 and Neko 2.0

This error happens before Site::main is even able to run.

The default haxelib.json has an empty license field (license = "") and therefore failed to install after the git clone with this: License must be one of the following: [GPL,LGPL,BSD,Public,MIT].

using "haxelib dev" will create a .dev with an extra / at the end, which seems to mess up things on windows:

haxelib dev anything .
haxelib path anything

Library anything version dev is not installed

Not sure if it's been fixed already or not, but then it is needed to allow sefldupdate for a fix

To quote Caue on this one:

For now, haxelib has a ndll folder, which is in the search path when using Lib.load(). The way it's organized isn't very good, since it mixes up 'platform' with 'OS'. For example, there is a Linux folder, but an ARM linux platform would need a different binary.
Also, it would be very nice to determine a folder structure for native builds, so it would be possible to do e.g. haxelib build-native somelib to build the native binaries for the current platform.

Lastly, now that we have e.g. support for native java libraries, maybe we could include a java .JAR when targetting Java?

haxelib git detox [email protected]:jasononeil/detox.git src

Ooops, that was wrong!

haxelib git detox [email protected]:jasononeil/detox.git master src

"Already up-to-date."

Oh, okay then.

Perhaps we should just delete the git directory if it already exists?

The existing remoting endpoint should remain intact.

Using "localhost:2000/" for the website, and "localhost:2000/api/3.0/" for the API, they use different paths:

Website: /root/haxelib.db
API: /root/../../haxelib.db

This would obviously be a good idea to fix...

https://code.google.com/p/haxe/issues/detail?id=1813

The current haxelib repo server has a very slow internet connection; downloading NME's 60MB zip takes more than 30min!

I can offer to sponsor a server that has better speed to solve this problem; but an easier solution would be to try to use CloudFlare on top of the sever.

CloudFlare is a free CDN (see https://www.cloudflare.com/features-cdn ), and it should speed up the server's upload rate considerably.

The dev path is saved as the relative path, so it won't be found correctly when compiling from a different folder.

Referring to https://code.google.com/p/haxe/issues/detail?id=1290, it seems that it is better to run production version of haxelib using MySQL.

But I agree that using sqlite locally is handy for development, so probably lets support both.

Hi

This new release of haxelib has made me give another try on it. Thanks for your work.

One thing I find annoying in dealing with haxelib is that haxelib.json need to be in the source folder along side package folder and source files.

This does not look very nice on a git repo for example where you want people to use "haxelib git ..." to grab your library.

Also if you want to have other files distributed (readme, license...) with your library they have to be put with the sources.

Could the json format allow a "classPaths" fields like this

"classPaths":["src","src2"]

most of the time only one source folder would be necessary but maybe there are some use case for multiple source folders (not any in my mind as of now but better safe than sorry.)

What do you think?

When a library is submitted with same version on both legacy and new haxelib, the legacy haxelib client will download the 3.0 library archive instead of the legacy one. This needs to be urgently addressed.

After thinking about #11 and how to keep the client small, I've had the following idea: Running haxelib <cmd> <args> could simply be a shortcut for haxelib run haxelib_cmd_<cmd> provided that <cmd> is unknown. This would allow us (and in fact everyone in the community) to add commands while keeping the client clean. The long prefix is simply meant to avoid taking up good names.

Thoughts on that?

More info here: http://semver.org/

Ok, Nicolas basically gave me a go yesterday night (we're still in disagreement over some issues but they are non-essential at this time), so let's get this show back on the road!

It might be best if we had a short IRC meeting regarding the next steps ASAP. Is everyone ok with March 27 at 22:00 GMT? Should be humane for most people, only poor Andy would have to get up at 6am ;)

Please leave a short note whether or not you can attend. If most people can't attend, we'll have to reschedule of course. But if it can take place, naturally we'll post a log for those unavailable.
The main objective is to devise a road map, not to get entrenched in discussions over details, so I think it should take an hour at most. I'll try to be prepared to make sure it all goes swiftly.

Until then, I think it would be best if we could put in some time to manually test the compatibility of the 2.10 client with the current server, so we know we can safely freeze that bit of the code base before moving on.

Just to make sure you all get notified: @andyli @delahee @Dr-Emann @jasononeil @jdonaldson @MattTuttle @skial @TheHippo @waneck

Everybody else is also invited to join of course. I suggest we meet in the #haxe channel and take it from there.

https://code.google.com/p/haxe/issues/detail?id=1808

safeDir can throw for several reasons, but getRepository swallows these reasons and assumes that the directory does not exists.

I think it would be nice to also give the Haxe lib site a new design, or at least adopt the design of the main Haxe page.

When I try to install an haxelib from git I've got the following error:

License must be one of the following: [GPL,LGPL,BSD,Public,MIT]

I looked in the genereated haxelib.json and there actually is no license set even if the is one set in the XML.
So I put a haxelib.json at the root of the git but the error's still here. I think the JSON is automatically generated even if there is already one. Am I right ? Is there a workaround ?

I created a helper tool to convert old haxelib.xml into haxelib.json. Would it be better to include it as a temporary haxelib command (we could deprecate it after a few months).

Sample implementation:

https://github.com/jasononeil/haxelib-xml-to-json/blob/master/XmlToJson.hx

Sample usage:

haxelib convertxml // converts haxelib.xml in current directory to haxelib.json

If it speeds up the process of getting new developers to push their libraries it could be worth it. Let me know.

Currently run.n is compiled by the library creator.
This means that potentially dangerous code could be downloaded to a client.
And because for some haxelib is installed so only root can use it, it is even more dangerous.

I suggest that instead of the library creator, compiling run.n, this should be done automatically by the user. This way at least you can read the source code.

I feel like there was some mention of this on the haxe mailing list, but I just want to make sure it gets to the issue tracker.

It would be nice to have haxelib check for updates to itself before running, so that it's possible to patch it without requiring a new release of haxe.

Redirect old haxelib requests to a separate legacy endpoint.

I recently experimented with testing haxe project using TravisCI and it is quite easy and useful. It can be used to unit test various haxelib commands.

I can setup a basic structure and make a pull request if you agree.

With reference to discussions at
https://groups.google.com/forum/?fromgroups=#!searchin/haxelang/haxe$202$20and$203/haxelang/trmq-4H1J8g/_qA6Ox3uO3MJ

haxelib binary which currently reads ~/.haxelib file to decide for haxelib path.
We should modify it such that "haxelib" binary and "haxe" etc bianries should first check for environmental variable HAXELIB_HOME (to point to haxelib path) and if it is not found only then it will look inside the file ~/.haxelib and so on.
The advantage will be that on the same machine and same login and we can have two simultaneous running two different haxe future versions pointing to two different directories using environmental variable.

FOR EXAMPLE: In case of java, i am demonstrating full workflow of simply running two java version (using environmental variables) SIMULTANEOUSLY:

   I launch one xterm/gnome-terminal/konsole/console
           export JAVA_HOME=/opt/jdk1.5                                 #so all the java runtime platform .jars will be pulled out of jdk 1.5
           export PATH=$JAVA_HOME/bin:$PATH                      #so my java executable, javac executable and all other executables will be pulled out of jdk1.5
           javac   Hello1.java                                                        #so jdk1.5's  javac executable is compiling using jdk1.5 libraries  (compilation time)
           java   -cp . Hello1                                                        #so jdk1.5's  java executable is running the class file using jdk1.5 libraries   (runtime) . It may be running as 24 hour running monitoring program(say) .


   Without closing the first xterm ; now   I launch second xterm/gnome-terminal/konsole/console
         export JAVA_HOME=/opt/jdk1.7                                 #so all the java runtime platform .jars will be pulled out of jdk 1.7
         export PATH=$JAVA_HOME/bin:$PATH                      #so my java executable, javac executable and all other executables will be pulled out of jdk1.7
         javac   Hello2.java                                                        #so jdk1.7's  javac executable is compiling using jdk1.7 libraries  (compilation time)
         java   -cp . Hello2                                                        #so jdk1.7's  java executable is running the class file using jdk1.7 libraries   (runtime). It may be running as 24 hour running monitoring program(say).

So we have two simultaneously running java programs running on different versions of JDK in different terminals on SAME machine at SAME INSTANT inside the same user (non-root).

In the same way, HAXELIB_HOME environmental variable will point to haxelib path.
This will also help in keeping the entire haxe library and haxe binary on a portable usb pen drive without touching any single file in users directory.

I recently switch to Haxe 3, so I had to re-install all my haxelibs.
So i tried haxelib install actuate and got:

Downloading actuate-1,6,3.zip...
Download complete : 1313 bytes in 0s (20.8KB/s)
Invalid Zip Data

Same things for all haxelib I tried (NME, TileLayer).

I'm on Mac OSX, and I installed Haxe-3.0.0-RC2 with the script on the website. The only trick: I keep haxe2 and I put a link usr/lib/haxe -> /usr/lib/haxe3.
I checked permissions, haxelib have them all on ./haxe/lib/. Everything else works fine (I installed haxelib from git or with local).

We have several things to accomplish when booting haxelib.

To make this easier, my suggestion would actually be to add only the very core of haxelib to the haxe installation. And rather than having it sit in the standard lib, it could actually be with the libs.

After Haxe is installed, we can do something along the lines of this:

# the following precludes that the compiler doesn't need haxelib for 
# -lib parameters, but I don't see any reason it should
haxe -lib haxelib -main haxelib.Client -neko haxelib.n
nekotools boot haxelib.n

# now we can do this
haxelib upgrade haxelib

# and recompile
haxe -lib haxelib -main haxelib.Client -neko haxelib.n -cmd
nekotools boot haxelib.n

Although there's no reason why the very first line couldn't just as easily be (if that's better):

haxe -main tools.HaxelibBoot -neko haxelib.n

The haxelib bootstrap core doesn't need to contain much in fact. No login, site, db or whatever. Only a barebone client capable of running the upgrade command by a remoting call to the hard coded end point. In essence, this can be dealt with in a few dozen lines (that will probably need little to no adjustment in the future).

Then the upgrade can get us all the things we need, like the full command set and hxssl and a builtin version of tetris ;)

As for booting the server, that's also something that needs consideration. I still think that the site and the remoting server should be two distinct servers to start with. On lib.haxe.org:80, we should have the site running (+ the legacy remoting endpoint). The remoting server itself could simply run on another port and should be buildable without any dependencies. Again, here we only need the api and the db. I believe the code can even become somewhat leaner with TableCreate.

Any thoughts on all this?