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:
- 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)
- 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_urlhas to be given with an URL to the license, also a file /LICENSE(\..*)/ (Plain-Text readable) has to be in the package-root.
- An array of libs the lib is depending on. Perhaps this should be split up into
dev_dependencies. The first is obvious, the latter lists requirements for development/contribution, like test libs.
- 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 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:
- 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.
- 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
- 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.
This is only a proposal which I will post to the haxe mailinglist, the actual specification (or rejection) will be discussed there as a follow up.
The discussion is available at https://groups.google.com/forum/?fromgroups#!topic/haxelang/KrYoVwRQilU
Also I opened a issue at github: https://github.com/HaxeFoundation/haxelib/issues/57