Wanting a singular packaging tool/vision

Just here to actually answer a question I kinda think @encukou misunderstood.

Most of the namespaced virtual provides are generated - usually based on the packaged files: for example from pkgconfig files or egg-info/dist-info metadata. This happens automatically as long as a specific RPM “script” that generates the provides for the given namespace is installed when the package is built (and we make sure that e.g. when Python is used during the build the generator for dist-info metadata is also installed).

Some of the other virtual provides (such as the python3-x → python3.11-x alias) can also be generated based on the actual names. But virtual providers can always be added manually.

Since we are getting a bit off-topic, feel free to ping me elsewhere if you want to know more.

1 Like

Yeah, it could start that way, which can often help prove the practicality and usefulness of the concept, produce one or more working implementations, and (perhaps most importantly) iterate on the details to

I suppose any tool could declare any semantics they want for their tool.<name> table, but at least IMO tools really shouldn’t rely on reading other tools’ sections; instead, other tools can adopt matching semantics for subsections of their own table, and then hopefully standardize them once they are tested, stable and useful. Otherwise, I worry we’re encouraging a regression to the days when the details of one tool’s implementation (Setuptools) defined the de-facto ad hoc “standard”.

1 Like

I agree. Is there a process for standardizing such commonality? E.g. do we go the PEP route, are there standard sections for general functionality, etc.?

It would either need a new dedicated section, be a new Pyrpoject metadata key/Core Metadata field (under Project), or be part of the yet-to-be-proposed section for extension building. In any case, the PEP process would definitely be the venue to standardize it.

1 Like