Use haxelib dev to handle path overrides.

[player-03]

By creating a few small files and setting the working directory, we can make Haxelib aware of a path override. This means we can call haxelib path directly, rather than trying to reimplement it.

For now, I'm leaving the second block (the one that used to be the else block), because otherwise it messes up the diff.

[player-03]

@Tutez64 @tobil4sk How does this look, in comparison to #2010?

[Tutez64]

I think this is a good idea, better than #2010

[tobil4sk]

Avoiding reimplementing haxelibs resolution logic seems like a good idea.

A path overridden haxelib may have non-overridden dependencies. In that case, haxelib path will need to see those dependencies in the local repo as well. Does this handle that case? (Maybe we should add some basic tests to ensure some simple cases like this work)

[player-03]

You're right, that's a bit less simple. I think f6deecb solves it, but it isn't very pretty.

---

I guess it's time to bring up my other proposal: let's deprecate path overrides. Haxelib is fundamentally not designed to allow overriding a single path this way, and fighting it just opens up opportunities for incorrect behavior.

Here's another example off the top of my head: <haxelib name="foo" path="./foo" /> <haxelib name="bar" />. If bar depends on foo, Haxelib will resolve that without Lime's involvement, importing the global copy of foo and shadowing the intended version. Swap the order and now at least the intended version shadows the global version, but any mismatched files or extra params will leak through.

And if the haxelib is accessed anywhere else in the build process, it certainly isn't going to use the hidden local repo. Luckily, most haxelibs aren't accessed from anywhere else, but Lime is, and overriding Lime's path breaks absolutely everything.

Importantly, there are better tools for this. For one-off overrides, users could use haxelib dev with a custom library name. If they need more control or have to deal with dependencies, they can maintain a local Haxelib repo. In advanced cases, they can use lix. All of these are far safer than letting Lime manage it, and the latter two can even override Lime's own path.