I was taking a look at the patches pip carries, and I noticed some of the changes only involve patching out various imports.
These could be rewritten by vendoring as well. Like before, these imports will remain broken and will fail at runtime. The difference is that rewriting them means they will never work, isolating pip from any packages the vendored code happens to opportunistically use if they're available. With this, we would shrink the breakage-prone manual patches we'd have to carry.
The main complication is that pip imports keyring from the environment if it's available for HTTP authentication. So, vendoring would also have to gain a configuration option to stop certain unfulfilled imports from being rewritten.
I have no idea who else uses this tool, but for the sake of not breaking them, this would likely have to be opt-in. Something like isolate = true or rewrite-missing-imports = true.
If this doesn't seem too magical, I'd be happy to work on this whenever my time permits!
I was taking a look at the patches pip carries, and I noticed some of the changes only involve patching out various imports.
These could be rewritten by vendoring as well. Like before, these imports will remain broken and will fail at runtime. The difference is that rewriting them means they will never work, isolating pip from any packages the vendored code happens to opportunistically use if they're available. With this, we would shrink the breakage-prone manual patches we'd have to carry.
The main complication is that pip imports
keyringfrom the environment if it's available for HTTP authentication. So, vendoring would also have to gain a configuration option to stop certain unfulfilled imports from being rewritten.I have no idea who else uses this tool, but for the sake of not breaking them, this would likely have to be opt-in. Something like
isolate = trueorrewrite-missing-imports = true.If this doesn't seem too magical, I'd be happy to work on this whenever my time permits!