clarifciaiton on --override and swapping
#2891
-
|
#2425 describes " swapping" an entire dependency. I may have such a case. I'm trying to work with a proprietary wheel [1] that uses the deprecated "Obsoletes" and "Provides" https://packaging.python.org/en/latest/specifications/core-metadata/ metadata to try to "replace" another wheel . Said proprietary wheel also includes forked code at the same import path as the package it purports to "Provide", so having both in a lockfile can quickly lead to runtime problems. I am aware that pip does not support this metadata and the scheme obviously doesn't work and creates a big mess. I'm exploring options in a lockfile to either:
I can see from the docs and examples how to use (In the above case I could create an empty dummy internal My preferred solution would be for the large well financed company to not be so... gratuitously messy with their packaging. My intent is to clarify the current capability, not ask for free feature work to circumvent proprietary problems. [1] https://pypi.org/project/databricks-connect/15.4.9/#files |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
1st stop should always be So That code is here (Note in particular line 40 where the project name comes from the requirement itself): pex/pex/dependency_configuration.py Lines 25 to 53 in 722a0b6 I think a full swap could be retrofitted unambiguously though, say using syntax like: |
Beta Was this translation helpful? Give feedback.
1st stop should always be
-h:So
--overridematches on project name, meaning you can override a project to come from a different version or source (say VCS), but you cannot change the project name itself.That code is here (Note in particular line 40 where the project name comes from the requiremen…