Next generation haxelib proposal about haxelib HOT 1 CLOSED

As discussed on the Haxe mailing list:

• url : we have url already. If we wanted to include a link to source, would you link to the Github or Google-Code page, or to the git:// or svn:// url? I think having a link to the git repo could be interesting and allow for easier switching to the latest development version. Perhaps you can make a new issue to discuss this.
• licence : It's not that we're against closed-source, it's just that hosting and distributing closed-source libs on a haxe-foundation owned server has a raft of legal implications. It's better to stick to a list of pre-allowed licenses that we know are legal to distribute. I think running a private haxelib repository is a good option for non-free libraries. The syntax would be haxelib -R myhaxelibs.com install somelib. That way you have control over your stuff, and could even implement pay-walls etc.
• dependencies: You can already have dependencies to a library. For dependencies when developing a library, run "haxelib install build.hxml" on the libraries build file to install all dependencies needed for building / testing.
• contributors: Merging the haxelib users with other haxe foundation accounts would be good, and then you could administer them via the web interface. There's a new haxe website coming at some point, maybe that would be a good opportunity to look into it?
• version requirements: The documentation is not great, but the syntax for requiring a specific version is found here: -lib mylib:3.0.0 in your build file. At the moment only exact version matching is supported, but the plan was to add some intelligent matching using the semantic versioning. Perhaps you can make a new issue to discuss this.
• haxe_level / standard_lib: At the moment these are linked - the standard lib version is the Haxe compiler version. We've reserved the lib name haxe, and if the compiler team will adopt semantic versioning, then we can "depend" on a certain haxe file by adding haxe as a dependency, as you would any other library.
• version compatibility: I agree with Juraj on this one. It's better to focus on the current migration rather than try to provide backward compatibility. The split was very deliberate, and most of the changes were made so that in future (Haxe 4 etc) we won't have to do an ugly split like this again. For now, most people seem to be switching over well enough though.

Thanks for taking the time to share your thoughts, we're probably on the same page with a lot of things, it's just a matter of time / implementation details. If at any point you want to help out, the code base is pretty approachable so fixing some bugs or sending a pull request is always appreciated! I'm closing the issue for now, even though some of the points are good and worth following, because it will be easier to track them as separate issues I think.

from haxelib.