This is a proposal for a potential solution to some common issues with packaging. The main idea is to let users define overrides for the package installers for the cases where the normal behavior is either broken because of poor package metadata or results in something that is not what the user actually wants.
Currently this proposal touches only on the UX aspect. It is born from questions that I keep seeing (on StackOverflow, here, and other places). And I guess this proposal represents the kind of answers I wish I could give.
I wanted to wait until this is a bit more mature. But there are other discussion threads going on right now, that I feel are closely related, so I thought I might as well publish this now and take advantage of this momentum. This still lacks structure, and looks like a brain dump rather than a fully formed proposal. This is a naive take that does not concern itself much with actual feasibility. And finally this is a work in progress, changes are to be expected.
What do I expect out of this? Personally I am not impacted by the pain points that this aims to alleviate, so in the end my interest is relatively limited. I guess, it was important to me to write down these ideas, whether something comes out of it or not. With all that said, feedback is welcome.
The full (live) document is here:
And the short of it is right below…
This is a proposal for a solution to help alleviate some frequent pain points with Python packaging. Mainly those things:
- Fix bad dependency requirements in metadata
- Fix bad build system in dependencies
- Provide more installation options per-dependency (
python -m pip install Application --overrides overrides.toml
overrides.toml looks like this:
[Library] requirements = [ "LibraryNightly[cpu]", ] [LibraryNightly] index-url = "https://index.internal/simple/" pre = true
In this scenario, the user wants to install
Application. But in case it has a dependency on
Library the user wants pip to install
LibraryNightly with the
cpu extra instead. Additionally the user wants that pip looks for
LibraryNigtly on an internal index exclusively, and that pip considers pre-releases of that
LibraryNightly. Other potential dependencies should be handled as usual,
including potential dependencies of