[deleted comments] [stage1] Haxelib replacement

01 sangohan.md

I think defining exactly what the role of the 'package manager' is (vs the build tool) must come first.

Package manager is a tool that both downloads, and resolves package and its dependencies. It does not have to be part of a build tool. I feel that conflating both the build step, and the dependency resolution step into one tool will not work in the haxe ecosystem (since haxe is a source->source compiler, and each output target has its own canonical build tools). Therefore, to make a haxe package manager work for all targets, it must set about defining a format for defining dependencies of the current project being compiled (which is then in turn used by other projects). This format must include a specification for a way to retrieve its dependencies for each target. I think extending haxelib.json to include more data, including the retrieval mechanism for externally compiled libaries, is the way to go.

haxelib.json :

{
  "dependencies": {
        "haxe" :[
            { name: "pure-haxe-lib-1", version: "3.4.64"},
            { name: "my-custom-lib", location:"my-custom-lib/src"}
        ],
        "java" : [
            { name: "some-java-lib-1", location: "libs/java/some-java-lib-1.jar"},
            { name: "some-java-lib-2", location: "libs/java/some-java-lib-2.jar"},
        ],
        "js" : [
            { name: "some-js-lib-1", location: "libs/node_modules/some-js-lib-1", hxml:"-D 'some_stuff'"},
            { name: "some-js-lib-2", location: "libs/node_modules/some-js-lib-2"},
        ]
    }
  }
}

This dependency will be hand written by the author of the haxe library/project. It is then up to the author of the project to work out how to put the required external dependency files in to the locations described by this file. haxelib.exe will parse this dependency description, and in the case of pure haxe dependencies, resolve transitives, and output a hxml file required to compile the current project.

I am deliberately not integrating any existing external dependency tool knowledge into the haxe package management, because any target output language is subject to change, and haxe is not able to continuously keep up. The authors of libraries need to figure out the best way to integrate it into the target language's ecosystem.

02 jcward.md

This format must include a specification for a way to retrieve its dependencies for each target.

Woah, woah, woah. Aren't we just talking about Haxe dependencies? Is there any merit in extending to target-specific (java/js/etc) external libs? Isn't that really the job of a build tool?

03 jcward.md

You know, the only thing really odd with haxelib today is that you specify versions globally for all projects (haxelib set hxfoo 1.2.3), instead of at the individual project level (e.g. in hxml, -lib hxfoo 1.2.3). Let's not forget that haxelib is:

• easy for users out of the box
• easy to contribute to
• has git support
• has a decent website
• user can build his own version-aware tooling around it (e.g. setup versions before each build.)

Consider this:

• The very idea that a project should be able to specify a versioned library sounds great, but it leads you down a complex road.
• If projects must specify dependencies, so must libs also.
• Then you need transitive dependency resolution.
• Then you need to deal with conflicts, perhaps providing options for overrides, version ranges, etc (e.g. the apt packaging system has keywords like depends, provides, recommends, suggests, replaces, breaks.)
• Assuming symver gives us some leeway in this (e.g. we can assume all 1.y.z libraries are indeed compatible), you then assume third party authors know and respect symver. What about mistakes? You then need a blacklist.
• How do git or local versions inter-operate with symver?

All this to say: managing versioned dependencies is complicated. And people have opinions based on their history (I like how apt works. I like how npm works. I like ...) Again, because haxelib today outsources version management to the user, we will by definition arrive at a system that's more complicated than haxelib today. But will it be more usable? Or better? Does it really belong in the compiler? I'd say it's unclear.

TLDR: I suppose I'm just skeptical until we see an actual proposal.