Ban negative extras (!= for extras marker)

Packaging
21

Purely from a standards process perspective, the question isn’t what tools do, but what the standard says right now.

The standard currently has defined behaviour for !=. You can argue that the behaviour is a bug in the standard. That’s fine, and the description in the OP here of the strange behaviour of != for extras makes that argument.

Whether tools implement the current standard correctly isn’t an argument for whether the standard should change. It’s simply an acknowledgement that current tools have bugs in their implementation of the standard. The fact that those bugs have gone mostly unnoticed is good evidence that a change to the standard wouldn’t be particularly disruptive, but it doesn’t, in itself, justify a change. And indeed, the fact that Poetry would be affected demonstrates that a change wouldn’t be 100% backward compatible (which doesn’t make change impossible, it just adds an extra consideration to the decision).

To be clear, I haven’t been through the arguments for and against the proposal yet. So I have no particular view on whether it’s an acceptable change. And as we’re viewing this as a potential text-only change, we’re not even in “PEP process” territory here, so my opinion has no special weight.

I will point to the process for minor fixes. It’s not particularly helpful, as all it really says is that this change (because it affects interoperability) must be escalated to DPO, and DPO will either approve it as a text-only change, or not. Without an explanation of how DPO should express that approval, this is fairly unhelpful. But it is the process we have right now[1].

Personally, I don’t see a good solution within our current processes. Breaking Poetry with a “text-only” change seems beyond the scope of “text-only”. But the PEP process is way too heavyweight for this. But all that’s really needed here is for someone to present a credible argument that “DPO has approved the change” and for the packaging standards editors (which doesn’t include me) to accept that and make the change.

  1. I’d strongly encourage the new packaging council to fix this - it’s a genuinely terrible process IMO - but until that happens I prefer to avoid debating governance and process change via DPO… ↩︎

2 Likes
22

As a non-standards-editor, the signal I’m looking for in this is whether any packaging tool is opposed to this change, or if we discover any specific problems with it. I’d let the ongoing discussion involving @dimbleby and @radoering run its course for now, and then we hopefully arrived at a consensus we can implement.

2 Likes
23

I think in Poetry, every use case with negative extras can be expressed by only using them within the tool.poetry section. It is not necessary to use them in the project section. Nevertheless, it is currently supported so that we would just deprecate its use at first.

Apart from being present in project.dependencies it can be considered internal to Poetry. (As pointed out in Ban negative extras (`extra !=` markers) by konstin · Pull Request #2085 · pypa/packaging.python.org · GitHub Poetry does not publish sdists/wheels with negative extras in the metadata.)

All in all, I think from Poetry’s point of view the following statement is fine:

It would even be ok if it SHOULD not be used in the project section of the pyproject.toml. In my understanding, this amounts to a deprecation.

6 Likes