No support of two or more git commit versions of the same lib
In the current state a git lib dependency is placed in some_library/git folder. And it is not possible to have two or more different git commit version of the same library. Nowdays it is not a rare case of dependency organization. For example, app depends on lib A and lib B, lib A depends on lib C(commit hash 1), lib B depends on lib C(commit hash 2)
Proposal:
two or more same git libs can be placed in like that: some_library/git/${commit_hash}/${lib_content}
E.g.
hxcpp/git/b306a2226ace9143dc0fb14541be2ae87a89a744/${lib_content}hxcpp/git/df44bfb623abaf2b004b2c65a025b84095cf0b7a/${lib_content}
This would be possible, but would require some more considerations
# how do we resolve this against the commit hashes?
-lib hxcpp:git:https://github.com/HaxeFoundation/hxcpp#master
# do we need to emulate git's short hash resolution?
-lib hxcpp:git:https://github.com/HaxeFoundation/hxcpp#b306a222
I've got local scope files WIP to replace hxml which would allow these issues to be avoided by always storing the full hash (alongside the branch name/tag). For those, each directory name could just be the full hash, but we'd want hxml files to keep working as they do now.
This would also require a migration and a .repoversion bump.
@tobil4sk thank you for reply. How can I track news about haxelib development progress?
@dja-in-space The best way is to look at the releases tab on the repo page, that is updated whenever a new release is published. You can watch the repository as well if you're interested in being notified individual changes that occur.
I also wanted to add, it seems I misread your original example. Even if haxelib has support for multiple versions of a git library at the same time, it would currently not be possible to have both versions of the library in the same project in the way you presented (A using C#1 and B using C#2). This is a current limitation of Haxe, which only allows one module of a given name, so either C#1 or C#2 will win and shadow the other, even if Haxelib could install both.
Haxelib being able to hold both versions would only help if two different projects depend on two different versions of the library. It would mean both projects can exist side by side without interfering with each others library versions. It is also possible to solve this problem by creating a local repository so a project can have its own copy.