Skip to content

Suggest changing the version of a package, as well as its dependencies #5969

Open
@ChickenProp

Description

@ChickenProp

Suppose I'm using packageB, which depends on packageA, and in my extra-deps I have

- packageA-1.0.0
- packageB-1.0.0

Additionally, this version of packageB has packageA < 1.1.0 as a version bound.

Now I update packageA to 1.1.0. (Or maybe it's in the resolver and I update that.) So I have

- packageA-1.1.0
- packageB-1.0.0

which isn't a valid combination.

Right now, stack suggests that I fix this by adding packageA-1.0.0 to my extra-deps. It would be great if it would also suggest changing the version of packageB that I specify.

I feel like this is more often what I need to do, especially when the problem is "the specified packageA is too new" rather than "the specified packageA is too old" or "there's no specified version of packageA". But even if it's correct less often than the current suggestion, having it in addition seems like it would be valuable.

A simple version of this might be to simply say something like: "try changing the version of packageB that you specify". That's not super helpful to someone who already knows to try that, but seems likely helpful to newcomers. A mild improvement on that might be to guess whether we should upgrade it (if all failing dependencies are above the version bounds) or downgrade (if all are below) or not guess (if it's not that simple).

More complicated would be to suggest an actual list of candidates. Maybe the ideal is something like:

  • Get the list of available packageB versions
  • Filter it for ones compatible with all other dependencies
  • Of those, suggest up to four or five: the most recent revision of the current patch number; the most recent patch of the current minor number; the most recent minor of the current major; maybe the most recent major-with-the-first-digit-unchanged; and the most recent major.
  • If there are no candidates after filtering, just suggest the same four-or-five, but from the unfiltered list, and note that they won't be fully compatible.

Though I'm sure there'd be edge cases to think about, and I don't really know what's possible with the current architecture. In any case I don't think this would need to be perfect to be useful.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions