ocaml
Unable to lock ocaml.org due to undeclared pin-depends in its dune-project
Running dune pkg lock in the ocaml.org repo produces the error:
Error: Unable to solve dependencies for the following lock directories:
Lock directory dune.lock:
Can't find all required versions.
...
- olinkcheck -> (problem)
No known implementations at all
...
- tailwindcss -> (problem)
No known implementations at all
...
The olinkcheck and tailwindcss packages are not in the opam repo and are pinned in this project's opam file but the dune-project file doesn't mention the fact that they are pinned.
Should we detect cases when a package is specified in both dune-project and an opam file but only pinned in the opam file, and use the opam pinning behaviour in such a case?
Should we detect cases when a package is specified in both dune-project and an opam file but only pinned in the opam file, and use the opam pinning behaviour in such a case?
In my experience it's usually simpler to have a single source of truth for metadata. I would assume that if a user wants to use pin-depends, they should really just stick to writing the opam files manually.
I'd say for now ocaml.org can write a workspace file with the pins set there.
That sounds reasonable. Do you think we should make it an error to attempt to lock a project with dependencies in its dune-project file that are pinned in the opam file? Similar to how the list of dependencies in both files must agree. The error you get when attempting to solve the project when the solver doesn't know about the pins is confusing since they are explicitly pinned in the opam file (which the solver ignores when the dune-project is present).
We could make it a warning. I imagine the pin-depends still have some utility with people that want to use both dune and opam simultaneously, or a subset of the team still uses opam
But specifically when running dune pkg lock, if there are packages pinned in the opam file but not in dune-project or dune-workspace, we know that the outcome will either be a solver error (if the package doesn't exist in the opam repo) or unexpected behaviour (if the package does exist but the pinned version is different). I can't imagine a scenario where attempting to lock ocaml.org in its current state will do what the user intended.
But it's impossible to express opam pins in dune-project/dune-workspace, and vice versa, so we can't require that if the package is described in both opam and dune-project, then both files must agree on pins. I guess the rule should be that if a package is spec'd in dune-project, then dune will ignore pinning information found in its opam file when locking, and print a warning if the opam file contains pinning info. Does that make sense?
I guess the rule should be that if a package is spec'd in dune-project, then dune will ignore pinning information found in its opam file when locking, and print a warning if the opam file contains pinning info. Does that make sense?
I think that makes sense, yes.
Btw, I don't think this issue is a blocker. It can be easily worked around by writing the equivalent dune pins in the project or workspace (recommended) file.
It's only a blocker in the sense that building ocaml.org is one of the goals of the package management MVP (though in this case the problem is with ocaml.org).
Is not writing any additional dune metadata a requirement? If we can afford writing some metadata, then the workarounds I proposed should be sufficient for now.
On Feb 22, 2024, at 8:16 PM, Stephen Sherratt @.***> wrote:
It's only a blocker in the sense that building ocaml.org is one of the goals of the package management MVP (though in this case the problem is with ocaml.org).
— Reply to this email directly, view it on GitHub https://github.com/ocaml/dune/issues/10120#issuecomment-1960710443, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB56YLUUCTW3HVJUZZ2DLYVAJYLAVCNFSM6AAAAABDWATFPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQG4YTANBUGM. You are receiving this because you commented.
I think for this issue it will be sufficient to send a PR to ocaml.org adding pins in their dune file.
I think for this issue it will be sufficient to send a PR to ocaml.org adding pins in their dune file.
Absolutely, that's completely fine for us (ocaml.org maintainers)
I agree. I would also recommend putting the pins in the workspace file for now so that users that don’t want to use alpha quality dune pkg can just continue with their usual workflow.
On Feb 27, 2024, at 6:23 AM, Stephen Sherratt @.***> wrote:
I think for this issue it will be sufficient to send a PR to ocaml.org adding pins in their dune file.
— Reply to this email directly, view it on GitHub https://github.com/ocaml/dune/issues/10120#issuecomment-1965866615, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB564MIBUDVM5QNSTK3L3YVV3VNAVCNFSM6AAAAABDWATFPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHA3DMNRRGU. You are receiving this because you commented.
Why is it that putting the pins in the workspace file will allow users to avoid using dune pkg?
I assume that some users are still using released versions of dune. Those are going to be slightly different from the dune we intend them to use - built from the main branch. So to make sure their workflow is undisturbed, we can move all the experimental stuff needed for package management into a separate workspace file that has to be activated with a command line flag.You could also just maintain the work in a separate branch as you’re doing now. It’s just that when the MVP is out, we’ll ask more people to experiment but we’ll still not have stability guarantees. So it would be good to minimize the impact for those not experimenting by minimizing changes to non optional metadata. On Feb 28, 2024, at 12:26 AM, Stephen Sherratt @.***> wrote: Why is it that putting the pins in the workspace file will allow users to avoid using dune pkg?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
You mean putting the pins in a custom workspace file other than dune-workspace which can be enabled with a command-line argument?
Yes, that’s how I would do it.
On Feb 28, 2024, at 1:23 AM, Stephen Sherratt @.***> wrote:
You mean putting the pins in a custom workspace file other than dune-workspace which can be enabled with a command-line argument?
— Reply to this email directly, view it on GitHub https://github.com/ocaml/dune/issues/10120#issuecomment-1968015892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB567MC7ZPBV2ITX4UY7TYV2BJVAVCNFSM6AAAAABDWATFPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRYGAYTKOBZGI. You are receiving this because you commented.
@tmattio I have created a PR adding a workspace file here: https://github.com/ocaml/ocaml.org/pull/2105