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

Better resolver failure messages #819

Open
fredrikekre opened this issue Oct 11, 2018 · 3 comments
Open

Better resolver failure messages #819

fredrikekre opened this issue Oct 11, 2018 · 3 comments

Comments

@fredrikekre
Copy link
Member

For example from https://stackoverflow.com/questions/52770092/julia-package-dependencies-in-travis-ci/52770252#52770252

ERROR: Unsatisfiable requirements detected for package SchumakerSpline [65e68595]:
     SchumakerSpline [65e68595] log:
     ├─possible versions are: 0.0.1 or uninstalled
     ├─restricted to versions 0.0.1-* by UnivariateFunctions [117ba14f], leaving only versions 0.0.1
     │ └─UnivariateFunctions [117ba14f] log:
     │   ├─possible versions are: 0.0.0 or uninstalled
     │   └─UnivariateFunctions [117ba14f] is fixed to version 0.0.0
     └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

is not very clear IMO. It would be nice to at least print which julia versions the package support etc.

@goerz
Copy link

goerz commented Oct 22, 2024

Even though we now show which versions particular packages support, this kind of "tree-view" should be considered internal state, and not shown as part of a user-facing error message. I would recommend keeping it as a @debug log only.

As for a user-facing error message, I think this could boil down to a simple message

Could not resolve the dependency for `PackageName`, available in versions <versions>

followed by two lines in one of the following formats:

  • Project <path> has a direct dependency on PackagName <version>
  • Package PackageA has a direct dependency on PackageName <version>
  • Package PackageB has an indirect dependency on PackageName <version> via <chain of packages>

The <path> would be the path of the project that is being instantiated, and PackageA/PackageB would be a direct dependency in that project.

There might be more conflicts than given by those two lines (which the current tree-view exposes, if you know how to read it), but I think as a user, I only care about the first incompatibility.

This is just an idea (possibly half-baked) that I want to throw out here from the black whole that is Slack

@araujoms
Copy link

araujoms commented Oct 22, 2024

While @goerz's solution is the ideal one, simply changing the current "restricted to versions <version> by an explicit requirement" to "Project <path> has a direct dependency on PackagName <version>" would already be a massive improvement, and is trivial to implement.

@KristofferC
Copy link
Member

Great with some ideas here and I would be happy to see some PRs with example error messages before and after this suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants