I’m not in favor of this PEP because it simply adds yet another way to specify Python dependencies without taking user feedback into account. Particularly, I find this a big red flag:
…it’s intended to be for single-file scripts only, and is not intended in any way to replace or compete with project metadata stored in
pyproject.toml
We’ve heard from many community members (e.g. the packaging survey) that they are tired of having to know the many ways to interact with Python packaging tooling and metadata.
While I believe your intent is, of course, benign, I don’t think end users will understand the subtle use case differences, and instead will have to reflect on the additional option they are provided alone. That’s especially unfortunate since I believe the proposed format doesn’t actually cover best practices like lock files and might have a chilling effect on the great work of standardizing on one file (pyproject.toml).
Essentially, I don’t think end users will know or understand the need for such a PEP, and will again have to expand their understanding of when and how to use which format for dependency specification.
As a reminder, respondents of the survey primarily
- found Python packaging too complex,
- did NOT prefer to use several Python packaging tools,
- preferred a clearly defined, official workflow.
But they also said, PyPA should
- focus on supporting a wider range of use cases,
- support more interoperability between Python packaging and packaging tools for other languages.
Given these key takeaways, I don’t see how this PEP would help users, as it would just add one more way to specify dependencies, without removing other options or integrating better in real-world scenarios.