One further point I would add is that I think we should try to keep the scope carefully focused. It’s all too easy to take “packaging” as a blanket term to cover everything to do with developing with Python in all its forms. While there’s a clear need in the user community for clarity and guidance in many areas, I think we need to be careful not to assume the packaging documentation (and more specifically the PyPA) has to cover all of that.
To make this more concrete, which of the following are “in scope” for the packaging documentation?
- Specifying package metadata and build processes
- Distribution of libraries for public use
- Sharing libraries privately between individuals/teams
- Creating standalone applications in Python
- Sharing Python scripts with their dependencies, between people with Python installed
- Project structure - for libraries, applications, data science, etc (many different use cases here)
- Tools and processes for testing
- Tools and processes for documentation
- Python environment management
- Non-python environment management (shared libraries, etc)
- Task runners
- Workflow, whether automated or manual
- Continuous integration and deployment
- Deployment of the Python runtime itself
All of these have at one stage or another been brought up in “packaging” discussions, but there’s clearly[1] no chance of covering all of that in any practical timescale. And there’s a lot of that which frankly isn’t the job of the packaging community. So I think it’s important that we try to come to some consensus on what is in scope, and then agree to restrict discussion to that scope.
For what it’s worth, this question of scope is just as much of an issue for any opinionated distribution or documentation - and there’s no reason that every such distro/document should make the same choices (for example, conda includes environment management, but as far as I know ActiveState doesn’t).
-
At least, it’s clear to me
↩︎