Make self update work on top of run mechanism

[ibilon]

See #172

Works for me, need haxelib.n next to run.n in the root folder.

[andyli]

It's great to see you worked so quick!
I will review it tomorrow as I'm too tired right now.

One question: Will existing haxelib able to selfupdate to this?

[nadako]

On windows, current selfupdate rebuild and nekoboots haxelib.exe which is actually the right thing to do if we want to migrate to the proposed mechanism.
On Unix, it treats haxelib as a shell script that does haxe --run which means it'll always run the latest version of haxelib.

[ibilon]

The separation run.n/haxelib.n may not be necessary indeed.
But we can't just nekoboot it for the haxe bundled version since that one isn't run through haxelib and doesn't have an extra parameter when run.

Didn't think of selfupdate to that version, mostly assumed people would overwrite it with haxe 3.3.

On unix it'll likely fail (can't change haxelib exe while running haxelib), but it's unrelated to this.

[nadako]

But we can't just nekoboot it for the haxe bundled version since that one isn't run through haxelib and doesn't have an extra parameter when run.

Why? We nekoboot it - it'll run without --safe and thus will search for haxelib_client and run it with the --safe flag.

[ibilon]

Because we pop the last argument in the run script, since it was added by the doRun function and we want to pretend it wasn't the case,
but when you run the exe the shell doesn't do that and we'd loose the last argument from the user.

[ibilon]

Actually we could add an argument to doRun to control the add of the cwd that defaults to true and pass false when proxying to the updated haxelib,
in that case we can simply have a run.n and nekoboot it for the bunded version.

That will prevent haxelib run haxelib_client from working, but since that's what haxelib does I don't see people launching that command.

Or conditionally add the cwd if the lib isn't haxelib_client, that's a little less clean, but would work.

[nadako]

Nice! Now what shall we do with the shell script...

[ibilon]

The one people have right now?
It'll get overwritten when they install haxe 3.3.

[nadako]

Well, and what if they just selfupdate without updating haxe? Will this PR still work through a shellscript?

[ibilon]

In that case, if the selfupdate works, the shell script will interp the main class, won't have --safe so it'll work the same.

If they selfupdate a second time (new version) then it'll still work, but the shell script won't be updated so they can't remove the old haxelib_client that was hardcoded in it (or move the haxelib folder, but that's already the case).

I guess we could try and detect it and replace the shell script with a nekobooted version of run.n,
but linux tends to lock the running file (why it doesn't work now)

[nadako]

In that case, if the selfupdate works, the shell script will interp the main class, won't have --safe so it'll work the same.

So it'll run shell->interp->run.n, right?

If they selfupdate a second time (new version) then it'll still work, but the shell script won't be updated so they can't remove the old haxelib_client that was hardcoded in it (or move the haxelib folder, but that's already the case).

That sucks, but maybe we could simply document the migration process, I doubt many people run selfupdate often or at all, since it's released really rarely.

I guess we could try and detect it and replace the shell script with a nekobooted version of run.n,
but linux tends to lock the running file (why it doesn't work now)

Is this also true for shell scripts? O_o

[ibilon]

So it'll run shell->interp->run.n, right?

Yeah.

Is this also true for shell scripts? O_o

Tried and it doesn't lock on shell scripts, which makes sense since they are not the one running.
So if we can detect it we can probably patch it with the executable.

[nadako]

Tried an it doesn't lock on shell scripts, which makes sense since they are not the one running.
So if we can detect it we can probably patch it with the executable.

TBH, I'm not sure it worth working on. This will complicate everything, because we have to check this each time on start and it's not clear how to detect that. Maybe it's really better to just document this one-time migration well.

[nadako]

So, I guess we're waiting for Andy to review this?

[nadako]

The commit history looks ugly now. Could you squash commits into one?
I'm really looking forward into merging this! I think we should do that ASAP so we can deal with remaining install/update issues, if there are any.

[ibilon]

Yeah, even more since I realized I was branching of master and not develop, I'll do that now.