Haxelib installation/bootstrapping

[back2dos]

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?

[TheHippo]

Another port is a bad for people sitting behind a strict firewall or required to use a proxy. If two server are used, then two different subdomains or just two different endpoints.

• http[s]://lib.haxe.org/ :arrow_right: site
• http[s]://lib.haxe.org/api/ :arrow_right: the remoting API

[back2dos]

Ok, maybe that way then. My main point was, they should be distinct ;)

[skial]

Having haxelib update itself will be really useful and a change of api endpoint is better than a change of port as the @TheHippo says.

:+1:

[jasononeil]

I don't mind doing things this way, but I'd probably be keen for Nicolas or Simon to weigh in their thoughts, unless you're happy for this to be a non-official way to do things. (We could do something similar even with the existing haxelib in place if we really wanted to. But foundation support would be smart I think).

+1 for using a different path for the API, rather than a different port.

Also, @back2dos are you aware the current haxelib script looks like this on linux:

#!/bin/sh
haxe --run tools.haxelib.Main $@

It's not even compiling to neko and running the binary. Not sure of the advantages/disadvantages either way.

[jasononeil]

Also, with your comment:

the following precludes that the compiler doesn't need haxelib for -lib parameters, but I don't see any reason it should

at the moment, I believe it actually does use haxelib. It calls "haxelib path libname" and haxelib passes back a list of classpaths the compiler should include.

If you're going to upgrade to the latest haxelib immediately on installation that shouldn't be an issue though.

[back2dos]

I have absolutely no interest in launching an alternative to haxelib. Certainly not at this point ;)

So yes, right now we need the "official powers" to agree that we can proceed in this direction. And by this direction I really mean the general direction, i.e. moving anything but bootstrap code out of the standard lib.

As for the neko-less alternative, it really looks intriguing, but I wonder whether that doesn't mean recompiling haxelib everytime you use the command. We could keep it that way, but then I' heavily suggest that the client stays as lean as possible.

[TheHippo]

@jasononeil: Regarding haxelib.sh: This was a leftover from #9 and fixed in c88c4e3

[back2dos]

Well in fact it comes from here: https://code.google.com/p/haxe/source/browse/trunk/std/tools/haxelib/haxelib.sh

[TheHippo]

Actually it comes from the git mirrow. It is interesting that the both files are different.

[jasononeil]

This is done as far as I'm concerned...