Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer to attempt again with conflicting deps unlocked when version resolution fails #3622

Open
lpil opened this issue Sep 15, 2024 · 10 comments · May be fixed by #3970
Open

Offer to attempt again with conflicting deps unlocked when version resolution fails #3622

lpil opened this issue Sep 15, 2024 · 10 comments · May be fixed by #3970
Labels
help wanted Contributions encouraged priority:medium

Comments

@lpil
Copy link
Member

lpil commented Sep 15, 2024

If you add a new dep it can fail due to conflicts with already locked versions of other deps.

I don't know how effective this might be, but I think we could do this:

  • When we have a version conflict
  • and some of the packages in the conflict chain are locked
  • offer to unlock those packages and try again

If we are on CI (we can look for CI related environment variables) do not offer this functionality.

@raquentin
Copy link
Contributor

What were you thinking for CI-related env vars

@lpil
Copy link
Member Author

lpil commented Dec 9, 2024

We can research what the popular CI platforms set.

@raquentin
Copy link
Contributor

One more thing, sry for spam, does "offer to unlock" packages involve some sort of cli action where user says like yes/no to update their gleam.toml, if so is there an example of another command setting up a series of cli fns in this way? Ty

@lpil
Copy link
Member Author

lpil commented Dec 9, 2024

I think we'd print the error, and then something like

Some of these dependencies are locked to specific versions. It may
be possible to find a solution if they are unlocked, would you like
to unlock and try again? [y/n]

@raquentin
Copy link
Contributor

Can you explain a bit more a case where this flow is triggered? I originally misunderstood "locked" a bit. Would this occur during gleam add <pkg> when <pkg> needs a minimum stdlib version of 0.3 or something but manifest.toml has it capped at 0.2?

@lpil
Copy link
Member Author

lpil commented Dec 10, 2024

Any time when resolution fails and the packages responsible for the failure are in the manifest, meaning they are locked

@raquentin
Copy link
Contributor

raquentin commented Dec 30, 2024

Got this working for the main case where an incompatibility is caused due to a locked file.

Would you also like this CI action to handle this case as well?

An unrecoverable error happened while solving dependencies: gleam_stdlib is
specified with the requirement `>= 0.51.0 and < 2.0.0`, but it is locked to
0.46.0, which is incompatible.

This happens when the manifest's locked version isn't within gleam.toml's specified range. The previous occurs when it is but there isn't a solution to the dependencies all together.

@lpil
Copy link
Member Author

lpil commented Dec 30, 2024

Would you also like this CI action to handle this case as well?

Sorry, not sure what you mean by CI action. Could you expand on that?

This happens when the manifest's locked version isn't within gleam.toml's specified range. The previous occurs when it is but there isn't a solution to the dependencies all together.

I think this may be a bug where a version isn't getting unlocked when the constraint specified in gleam.toml is edited.

@raquentin
Copy link
Contributor

raquentin commented Dec 30, 2024

Meant CLI action, being pausing the flow of the CLI to wait for the user to respond y/n to automatically unlocking.

And ok interesting, I'll look more into it

@raquentin
Copy link
Contributor

Marked linked pr as ready

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Contributions encouraged priority:medium
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants