rip: rip does not follow spec for handling of pre-releases

Currently rip does not accept a pre-release if there are no other packages, but the documentation states the follow: https://packaging.python.org/en/latest/specifications/version-specifiers/#handling-of-pre-releases

By default, dependency resolution tools SHOULD: … accept remotely available pre-releases for version specifiers where there is no final or post release that satisfies the version specifier

But rip excludes all pre-releases even if nothing else is available:

e.g. cargo r -- opentelemetry-exporter-prometheus rusults in:

  × Could not solve for the requested requirements:
  │ The following packages are incompatible
  │ |-- opentelemetry-exporter-prometheus * cannot be installed because there are no viable options:
  │ 	|-- opentelemetry-exporter-prometheus 1.12.0rc1 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 1.10a0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.42b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.41b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.40b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.39b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.38b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.37b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.36b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.35b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.34b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.33b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.32b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.30b1 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.30b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.29b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.17b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.16b1 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.16b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.15b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.14b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.13b0 is excluded because prereleases are not allowed
  │ 	|-- opentelemetry-exporter-prometheus 0.12b0 is excluded because prereleases are not allowed

In my opinion there should be an option to force exclude pre release packages and keep this behavior, but this does come up in the Python ecosystem naturally: https://github.com/prefix-dev/rip/issues/74#issuecomment-1841835301

By the way, my understanding is Pip’s behavior is to do this when collecting packages, but not when backtracking transitive dependencies, I have a question on the Python board if this is really following the spec: https://discuss.python.org/t/handeling-of-pre-releases-when-backtracking/40505

About this issue

Original URL
State: closed
Created 7 months ago
Reactions: 3
Comments: 18 (10 by maintainers)

Most upvoted comments

Talk of pip’s “intended behaviour” basically comes down to a couple of pip maintainers (one of whom was me) having mentioned what they thought pip did as part of a discussion. It was a statement of what we think the code does, not a claim that it’s intentional (much less that it’s intentionally different to the spec!)

Apologies, it seems I misinterpreted some statements.

IMO, pip isn’t following the spec, but it should be. That’s a bug in pip. That’s all. It’s not a bug we’ll be able to fix quickly (so if rip follows the spec, it will behave differently than pip in some edge cases, probably for some time) but it is “just” a bug.

I have been confused on this point over the course of this conversation, because of you saying that the spec says SHOULD and MAY that Pip could be interpreted as not violating the spec (which, in some sense, I am taking to have an equivelence as “following the spec”).

I think this, with an outlining of behavior of what the code in Pip does, and the highlighting that Pip may have implemented this behavior before there was a spec, is what led to my mistaken assumption of Pip’s “intended” behavior.

notatallshaw on Jan 11, 2024