pinning dev versions of packages makes opam hard to use

[yomimono]

I often want to use a pinned dev version of a package. If the package dependency version numbers have upper bounds, dev cannot fulfill them (for example >= 0.3.0 & < 1.0.0). The pinned version of the package can't be used. Faking the version number is ugly and cumbersome. Can we modify the bounds check to consider dev to be included in any bounded range?

/cc @linse

[avsm]

You can specify a version number to pin to get around this: opam pin add foo.0.9 <path> will pin the package as 0.9 and thus respect the constraints. There is also a --ignore-constraints-on option that seems relevant, but that I've never used.

[AltGr]

Yes, you have two options here. Assuming you want to pin foo.dev, which has depends: "bar" {< "1.0.0"}, and you have bar.1.0.0 installed:

• Use opam pin foo --ignore-constraints-on bar. This is transient though, meaning the next opam commands will try to "fix" the unsatisfied constraints (probably by removing some of your packages...)
• Use opam pin foo --edit, which will pop an editor of foo's opam file. Just remove the upper bound constraint on bar, and you should be good to go.

Now I am re-reading your question and thinking that maybe your problem was the other way around: you want to pin foo.dev, but have packages installed on your switch that depend on foo<1.0.0 (and you don't want them removed!). You can still use the transient solution --ignore-constraints-on foo, but the pinning trick won't work in that case, indeed. That's basically the reason why opam defaults to (or used to default to ? I remember there were arguments against it) the latest-known version when you pin a package and no version was specified.

Of course, you can still change the declared version of foo with opam pin --edit, but I can see that this is indeed cumbersome. I am not sure what a sound design could be: we probably don't want to ignore all constraints on dev-pinned packages either ? A good solution could be to store the --ignore-constraints-on packages somewhere on the switch to make them persistent, but I don't know at this point if it would be worth the added cost in code, and mostly interface complexity (we would need commands to check and edit this list too, and that can cause harder-to-debug situations ?)

What do you think ?

[AltGr]

Forgot to mention that there is a shortcut to customise the version of a dev package when pinning. It won't help with you seing a "fake" version (but opam helpfully adds a * to show it's pinned), but at least it's lightweight... if you know about it:

opam pin foo.VERSION git://...

will do the same pinning, but register your pinned version as VERSION without having to edit by hand.

[dra27]

opam 2.1 adds --with-version which allows pinning (quickly) to any version, so I think we can view this one as solved? Please re-open if not!