haxelib path extensibility about haxelib HOT 2 CLOSED

Having a single, homogeneous solution on the client side makes development of 3rd party tools easier. You can simply grab lib haxelib_client and build your stuff on top of that (some refactoring might be necessary, but patches are always welcome ;)).

So I am not really in favor of the proposal, but I do have a counter-proposal to make, that might solve your problems just as well.

One of our next steps is to make it easy to setup 3rd party haxelib repo servers and configure those in the client. Isnt't that maybe a better point to hook in?

If the general internal architecture of the haxelib server doesn't suit you, you only have to implement this interface: https://github.com/HaxeFoundation/haxelib/blob/master/src/tools/haxelib/SiteApi.hx

IIRC, Massive uses github for their proprietary stuff also. I think a read-only implementation of said interface on top of github (or possibly an arbitrary repository server) shouldn't be too hard. You need:

• search: construct the information from all (private?) projects owned by massiveinteractive
• infos: grab the haxelib.json of all release tags of a given project and construct the information from there (you might want to cache that, or to rebuild that during a commit hook or something)
• postInstall: this could just be a noop

The biggest weak point I see in this scenario, is that the haxelib.json isn't ever validated until it reaches the client, where it's basically a little too late for mistakes to show up. But that should be manageable.

If you feel like it, we can have a short meeting in Skype/IRC on that later this week. Just send me an email for the details.

from haxelib.

@dpeek another solution is to write your own front end that replaces haxelib and eventually fallback to it

from haxelib.