Proposal: overrides for installers

[sinoroc]

@NeilGirdhar

My proposal would be to do the work in multiple PEPs:

Yes, this needs to be split, no doubt about it.

@NeilGirdhar

A PEP to allow (possibly editable) path dependencies to pyproject.toml (poetry has this already),

I am against this. Abstract dependencies belong in pyproject.toml, concrete dependencies do not. Maybe you meant overrides.toml in which case, yes, that is one of the main drivers for this proposal.

@NeilGirdhar

A PEP to interpret a very simple overrides.toml that simply modifies a pyproject.toml.

Sure, why not. Not what I have in mind, but we’ll see, maybe it comes naturally as an extension of what I have in mind.

@NeilGirdhar

A PEP to provide additional indexes in a pyproject.toml and connect them with dependencies (poetry already has this feature, which they iterated on multiple times; it may be worth comparing any proposal with their solution)

That is just one aspect of what this proposal is about (But again, NOT in pyproject.toml! From my point of view Poetry got this wrong.). For me right now it is hard to see if it is a good aspect to use a starting point.

To be fair, I also kind of lost track of all the use cases I considered in this. I would need to find time to get back on this topic.

There were a couple of categories I thought of:

• Make it possible to use installation modifiers that are currently global, per dependency instead. For example pip’s --pre option (which kind of triggered me reviving this thread). See also how it has been added to PDM. And the big one would be if it were possible to specify one --index-url option per dependency.

  Having all these as CLI flags would possible become quite unreadable, so maybe a separate file used as input to the installer would be better.

• Override faulty package metadata. Typically offer a way to override eager upper caps on version constraints.