Explicit git Haxelib dependencies in referenced projects can not be overridden with 'dev'

[onehundredfeet]

If you have a library with a haxelib.json

{
    "name": "something",
    "url": "https://github.com/person/something",
    "description": "something",
    "dependencies": {
        "something_else": "git:https://github.com/person/something_else.git",
    }
}

And then in a project .hxml you have: --library something

And then run the following: haxelib dev something_else ../something_else

Compiling will still look for the git version even though you have specified dev in haxelib. There doesn't seem to be a way, at a project level, to override specified dependencies in haxelib.

haxe compile.hxml

If I'm missing something let me know.

There is a work around:

If you add the dev library to the project level .hxml it will pick up the dev version.

--library something_else
--library something

This is not obvious behaviour.

[onehundredfeet]

Sorry for the wrong depot Simon.

[tobil4sk]

This issue is somewhat related: #249.

Right now, dev libraries are handled the same for both -lib name:1.2.0 in hxml or {"name" : "1.2.0"} in haxelib.json. So, what would need to happen is to treat these differently. However, it could be argued that it would be a bit inconsistent to do this.

[onehundredfeet]

I was mistaken, the --library specification without the git behaviour seemed to fix the issue but no longer does. I agree, the hxml and haxelib.json should use the same spec.

Here's the behaviour I'm seeing:

if the git version is mentioned anywhere in the dependency library chain, then it will use that instead of the dev version. Maybe there's an ordering issue which makes it random, but I haven't been able to identify it. The next step I guess is to look at the code.

To be clear, this is a behaviour I'm seeing with the haxe compilation interaction with haxelib.

[tobil4sk]

You can test this out more easily by running haxelib path something_else something, with the library names in the order they appear in the hxml. This way you can confirm whether the library paths are correct, as this is what Haxe uses under the hood. I have tested this out both on the current development version and on the last release (4.0.2) and it seems to work as you originally described in the first post.

Based on what I know about the code, the libraries are resolved in order, so if a --library flag is given first without a version specified, the dev version will override it then, and future references to the library (e.g. in haxelib.json) will not change the version used. Although, beware, if there are two places where versions are explicitly specified and they conflict, the project won't compile. I tend to avoid putting versions in haxelib.json for this reason.

[onehundredfeet]

Ok, that seems to be what I'm seeing as well. I you specify a --library unversioned BEFORE it's every included in any dependency, it seems to block being overridden.

This behaviour is very non-obvious and would point to the versioning / dev specification system being insufficient to handle version mismatches in the dependency chain, as you describe.

I'm not sure how'd I'd fix this tbh. I'm going to think about it for a bit. I think it's much more obvious for regular version conflicts, the 'dev' wrinkle makes it much less transparent.

It would be nice to at least know when a library version is being 'shadowed'

[tobil4sk]

I think some of these concerns will be resolved once a better library resolution system arrives, which will allow locking library versions within a project so it is clear which versions are going to be used. Hopefully, such a system will make is easier to handle dev libraries as well.

The issue is that haxe does not allow multiple versions of the same package/module in a single compilation, so having conflicting library dependencies is a problem that haxelib cannot solve, which is why it just gives an error. It cannot really do anything else in such a situation, which is why I say it's better to avoid specifying dependency versions in haxelib.json.

Instead, you can have a libs.hxml file in your main project which specifies all libraries and their dependencies like this:

--library somelib:git:https://github.com/person/something_else.git
--library otherlib:1.2.0

You can then ensure the correct versions are installed using

haxelib install libs.hxml --skip-dependencies

Unfortunately, this does not really solve the issue for a library author trying to recommend a version of a dependency that works.

[onehundredfeet]

What I've done is create a 'devlibs.hxml' that I include in my compilation first and add any dev libs to it. Works ok for now.

[onehundredfeet]

The issue that I have is that some of the dependencies are only in GitHub, or require using the latest git version, so installing them manually is a pain. I thought I'd figured out a nice way of doing it with the library.json files. The hack above seems to work ok as a patch until a better system is in place.

[onehundredfeet]

And..... my work around stopped working for no obvious reason. I'll give up on the .json dependencies for now.