HashLink vs Neko

[ncannasse]

Just a few things we might want to discuss/decide before releasing Haxe 4.0 final. I'm planning to have HashLink replace Neko in the long term, so we should maybe start doing a few things in that direction:

• [x] haxe -x should use eval target instead of neko one
• [ ] haxelib run should check for Run.hx and run.hl and execute either with eval or hashlink
• [ ] try if haxelib can be run using eval instead of Neko
• [ ] open haxelib question : can we find a way to tag libraries as requiring haxe 4 so that they don't get downloaded by people still on haxe 3 (they would get the oldest version not requiring haxe 4)
• ~we should install HashLink with 4.0 installer additionally to Neko~

These are open to discussion, in case I overlooked something.

[ibilon]

If neko isn't installed the user won't be able to do haxelib run on the libraries that use neko, many of which aren't likely to see an update to fix that.

[Simn]

Yeah, haxelib run is the main reason why I didn't pursue this line of thought...

[ncannasse]

@ibilon right, I have modified "instead of" by "additionally to"

[ibilon]

On the open haxelib question we can tag them, but no matter how it's done the haxe 3 haxelib client will ignore the tag and just download.

The only thing I can think of would be to add a haxe 4 only repository and for the new haxelib to use it and the current repo, from the client side it'd probably wouldn't be that complex, but the submission and management of library that becomes haxe 4 only would be a big mess.

Note that haxelib has a much better update mechanism now, including messaging the user about available updates, so that could help.

[ncannasse]

@ibilon yes for haxelib this requires working on the server side so older (pre 4) haxelib clients requests will be filtered without libraries marked as requiring haxe 4

[Simn]

haxe -x should use eval target instead of neko one

Turns out that's already the case.

[futagoza]

sorry for the bump 🙏

Regarding the open haxelib question:

NPM checks the engines field in a package.json when installing; Why not add something similar that library creators for Haxe can optionally add to their published library's haxelib.json, and when it's being installed haxelib can check if this optional field exists?

Just my 2 cents while checking whats left before Haxe 4 comes out 😆

[Simn]

Moving this to 4.1 as I don't see anything happening here for 4.0.

[ncannasse]

@Simn could you just do the following: in haxelib, if there's no run.n but there's a Run.hx, haxelib run should run it with eval. I think that's a first necessary step towards deprecating Neko and we should ship a haxelib supporting that in 4.0-RC+

[Gama11]

I think that's been supported for a while, but you need to specify the main class via "main" in haxelib.json: https://github.com/HaxeFoundation/haxelib/commit/576b4b6466e345eb537f8f6e24e0f8fe252aca58

[nanjizal]

https://github.com/HaxeFoundation/hashlink/releases ( windows only ) ?

[Simn]

Moving this to 4.1 because the explicit "main" feature should really be good enough.