The issue comes from the fact that we need to decide whether a package should be updated from the manifest; but the manifest information is still likely incomplete (tag or version or commit only), as we don’t have to download anything yet, while the cached one has all metadata. So the “safe bet” was to assume that an update is needed. This can trigger updates that are not strictly necessary.
I’ve opened a PR here which I believe should have fixed this issue, as it restricts the comparison to only the field that was specified in the manifest: can I ask you to take a look at that and let me know there if it now works for your case?
The new edge case is now if I request version x.y.z and the cached repo has the same version field, but not necessarily the same commit ID I would get from git if I make a request based on the version tag. There is no solution to this unless we force-update (which we can still do via fpm update.
the PR also preserves the topmost (closest-to-manifest) dependency instance as the priority one, when two versions of the same package are requested by different dependencies. This keeps behavior backward compatible like @everythingfunctional observed. Please note that version constraint resolution is not a feature yet though, so decisions will need be made for the next release and we’ll hopefully find a solution that’s viable for the most people.
Thanks a lot for this useful information. Unfortunately, setting this option in the fpm.toml doesn’t resolve the problem for me. I still get the same error.
Rather than this, I would suggest to indicate which version of fpm a given input was known to work with. For example if the TOML manifest specified
fpm_version = 0.8
then fpm would know that it has to apply those default settings, which were active in version 0.8. That way, manifest files would remain valid almost forever, unless one introduces changes which can not be handled/converted automatically (as far as I understand, the current changes could be handled easily automatically) But otherwise one could easily introduce changes in keyword names, default behavior etc. without breaking backwards compatibility. Merely, one would have to provide an internal converter within fpm, which does the conversion on the fly. (We have a very similar input versioning in our code, and despite of several major changes in the input, we can still process input files written one decade ago.)
Exactly, I was going to say the same thing, but you beat me to it. You must specify one exact version of fpm that is known to work. Then if a future version of fpm changes defaults, it just converts old defaults to new ones, not a big deal.
We currently don’t strictly version input schema revision as other Fortran projects do (like DFTB+ ). When wrote the first prototype in TOML Fortran I did included a manifest version and a compatibility update, but I thought that for the current development model of fpm it would be much of an overhead to trace back very change from 0.1.0 to the current version. Especially testing whether the current and previous version give the same result would be a huge demand. But maybe it is worth to start introducing it at some point.
I think it’s a good time to start, so that we get into the habit. Yes, I agree that “we reserve the rights” to break anything until version 1.0, but having the versioning in place would be helpful and I think it wouldn’t cost us almost anything maintenance-wise to have a simple table that translates historical defaults to new defaults based on the version.
I fully agree. Now that fpm seems to become more popular, it is probably indeed a good time to start with the automatic compatibility conversions. Additionally, it may also further lower reservations toward fpm, as people would have to fear less that their manifest files become invalid from one day to the other. Especially, if one promises only to introduce non-convertible changes at major version changes. (And actually, it would be a much nicer/smoother solution than cmake_minimum_required_version…)
We just released fpm version 0.8.1, which introduces hotfixes for unnecessary dependency updates. Many thanks to @urbanjost, @everythingfunctional and everyone who contributed to the debugging.
Find the full v0.8.1 release notes here or on GitHub .
). When wrote the first prototype in TOML Fortran I did included a manifest version and a compatibility update, but I thought that for the current development model of fpm it would be much of an overhead to trace back very change from 0.1.0 to the current version. Especially testing whether the current and previous version give the same result would be a huge demand. But maybe it is worth to start introducing it at some point.