floooh
Ability to override imports in imported modules
Something ike this would be incredibly useful to have:
http://doc.crates.io/guide.html#overriding-dependencies
Ok, I think this should fairly easy to implement, we just need to make sure that a fips.yml import definition encountered first will not be overriden by later import definitions in imported modules, that way, a 'frontend project' can override any definitions of imported modules, no matter how far down the dependency tree they are.
This already works this way, isn't?
What I do here is to override things by cloning manually from other repos that have the same name and fips will promptly ignore it the directory already exists (it will check the repo status but not if the repo is indeed the specified one).
This is somewhat a workaround and I think that changing fips.yml to do the override is intrusive, I would prefer something in the line of a fips-overrides.yml that is .gitignore'd and has priority over fips.yml (loaded before and merged with).
But anyway, I'm really fine with doing cloning manually and this is a nice workflow, the problem is that sometimes I forgot that I've overridden something as fips do not print anything as warning for example.
I tried yesterday to use the new rev: feature for fips-glfw in my voxel-test demo, and this seemed to be overriden by other fips-glfw imports in imported modules, I wonder if it worked before (never tried it) and regressed with this commit: https://github.com/floooh/fips/commit/1d0f1a98ec255e0d4baaa8baf9f21d9e74564bb7#diff-bcc0885d174a726105f9bd8b5e888854R252.
I think the importance of 'import order' was not clearly defined before (at least I haven't really thought about this until recently).
If we have two entries fips-glfw how does this temporary file will be generated?
I think the order should not be important (from the project management view), so I think that sorting the import shouldn't matter at the end. But then something will be needed to find the common ground when importing things already imported.
This duplicate dependency resolution is hard, and we should not tackle it as one would expect.
So trying to keep it simple, I would suggest something like:
- if imported dep does not have restrictions (branch, rev, tag) and there is another that has, then that one wins preference;
- if two imported deps does have restrictions, then we must halt with a error message explaining, and the project maintainer should find the solution accordingly to project needs.
I would think that the top-level project (for instance if I'm creating a stand-alone Oryol demo, which has Oryol as a dependency) should have the last/definitive word on overriding dependencies, even for second-level dependencies (lets say I want to force a specific fips-glfw revision I would add a fips-glfw import to the top-level fips.yml which would override the imports of all dependencies).
True, if dependencies force revisions on their own, then it will become a mess, and an error message is probably best.