Running and upgrading haxelib

[ncannasse]

After a discussion with @jgranick, I agree that we need to make sure that users can easily upgrade haxelib so we can introduce new usages without waiting for a new haxe release.

Maybe we should always use the haxe macro system on all OS (including Windows), and make sure that we can update the client by saving it into a directory we are sure the user has write access. I'ld surely like to hear what people think about good locations for that ?

[jgranick]

I propose that C:\HaxeToolkit\haxe\haxelib.exe should become a small shim.

If the user has not setup haxelib, it should be able to find a default install of haxelib_client, included with Haxe. This could be located under C:\HaxeToolkit\haxe\std\tools\haxelib_client for example.

If the user has setup haxelib, it should look for a "haxelib_client" package in the haxelib local repository, for example, C:\HaxeToolkit\haxe\lib\haxelib_client\3,2,1

In the Lime and OpenFL tools, I use a simple script like this:

var args = Sys.args ();
var code = Sys.command ("neko", [ "tools.n" ].concat (args));
Sys.exit (code);

I believe @ncannasse said that not being dependent on Neko would be preferable, so haxe --run against the current haxelib_client should also work.

Benefits

You would be able to update the haxelib_client automatically using haxelib upgrade like other libraries.

You could haxelib dev haxelib_client path/to/dev/directory to work on improvements to haxelib

You would not need to use sudo access on Mac or Linux to replace the "haxelib" executable, it would be a shim that does not need to be replaced for an update.

I would be happy to help implement this

[back2dos]

I will see to it that haxelib becomes a .bat on windows, that just launches a haxelib.n, which we can replace while running.

The haxelib dev haxelib_client approach sounds nice, but that wouldn't work since in order to run haxelib we'd need to call haxelib path haxelib_client, so that's kind of a chicken and egg problem.

[jgranick]

So currently, haxelib.exe is the haxelib.n + Neko boot.

I was thinking, the shim could use Neko boot, but could use the Neko "loadModule" code in order to find the haxelib_client.n file. This would not require Neko on the system, nor would it require the Haxe executable (helping to avoid a chicken-and-egg problem)

Yes, it would need to find the path, but the shim would need to understand this logic itself. That would be the only shared functionality. Worst-case, you have a haxelib shim that doesn't understand how to run a haxelib_client from an eccentric new source. I think it's still a good step forward.

You cannot do a batch file on Windows, because that would make a calling batch script exit immediately. I just had this problem recently with the "openfl" and "lime" scripts.

I'm running this through Neko + Neko boot to create an executable instead:

https://github.com/openfl/lime/blob/master/tools/AliasScript.hx

This could instead be logic for finding the haxelib_client and running that

[back2dos]

I don't understand why I can't use batch files. Can't the calling batch file use call or start a new cmd if it wants to continue on failure?

[jgranick]

The user expects to be able to create a batch file like this:

haxe Build1.hxml
haxe Build2.hxml
haxe Build3.hxml

Similarly, I think they would expect the same of haxelib:

haxelib run lib1
haxelib run lib2
haxelib run lib3

Sure, it would work if they used "call" but I don't think people will catch that they had to do this. A simple self-executable (like the one I linked) keeps things working well within other batch files, while still forwarding commands to the next link in the chain as expected

[back2dos]

I'm not exactly sure that this is a sensible expectation. If there is an error, I would expect it to terminate the script instead of continuing. I think error suppression should be an opt-in, as permitted by call. Does anybody else have an opinion on this?

[jgranick]

Oh, no... batch scripts would exit after the first call, regardless of whether there was an error. It would simply only call the first instance of "haxelib" and exit.

[back2dos]

Sorry, got confused. In the second case that would indeed be an issue. In
the first one it shouldn't though, since -lib arguments get handed through
the compiler first. But you're right, they both should work. A shim it is
then.

On Mon, Mar 9, 2015 at 7:40 PM, Joshua Granick notifications@github.com
wrote:

Oh, no... batch scripts would exit after the first call, regardless of
whether there was an error. It would simply only call the first instance of
"haxelib" and exit.

—
Reply to this email directly or view it on GitHub
#172 (comment)
.

[ibilon]

Like @andyli said in #283 we can't tell people to update unless selfupdate works :)
And it doesn't, not on linux at least (you can't write the haxelib exe while you are running it).
So let's fix it for haxe 3.3 :)

Currently it's in two steps:

• get the latest version
• change the exe to the new one (ok a script, but that's the same thing)

The first one is done with the install/update mechanism and has no issues,
it's the second one the issue, because we used something specific and fragile and it doesn't really work.

This issue propose to use the run mechanism, which we know works.

I've tried this

var args = ["haxelib.n"].concat(Sys.args());
args.pop();
Sys.exit(Sys.command("neko", args));

as run script for haxelib, then I tested all commands and saw no issues,
(haxelib run haxelib_client list for instance) and even when having a dev version of haxelib set to the git version (after adding the run script ofc).

The difference from what is proposed here is that I wouldn't make the bundled haxelib a shim,
simply it'd check if haxelib_client is there and no --safe flag is toggled then run it.

That way once selfupdate (which is really just an update at this point) it'll use the set version of haxelib_client, which should be the latest update, or a dev version.

And if something is broken there's always the --safe to use the bundled version normally and fix things.

[nadako]

That sounds good actually. So we can bundle a nekobooted executable everywhere! \o/

[ibilon]

Didn't use a nekobooted version since that's os specific.

edit: oh I think I understand what you meant, that was about the bundled version next to haxe

[ibilon]

Removing the haxelib script would fix these: #191, #207, #189, #72 and #121

[nadako]

I think because we're moving to use a compiled neko version, we can also remove this nonsense and use macro \o/

[nadako]

This was implemented in #291