Hello,
First post, so short introduction:
I'm mostly working on Django projects, currently for 3yourminD in Berlin.
Working with python / Django for 6 going on 7 years. Also experienced in PHP,
some Js and build systems like docker.
We're currently migrating everything to docker and pip / requirements.txt
isn't cutting it anymore and I've tasked myself with looking for or building
an alternative tool.
This weekend I did quite a bit of research into the packaging tools and came
accross PEP 518. What it doesn't address is that there now is a file resvered
that declares very little. It does not declare and define sections to serve as
a deployment file for a project and apparently it is unclear to tool builders
what the one section is does define is supposed to be used for.
Case in point: poetry doesn't add itself to the build-system table when
writing the py-project.toml file. Which, as I read it, it should. Ideally,
every tool.${name} should be in the build system?
So, can we improve the file specification and introduce sections that allows a
project (not a library) to specify how it should be built? Right now, this is
all off-loaded to the tools that use the file and one cannot rely on anything.
It also makes migration from one tool to another difficult and cooperation
between tools hard. Or is this intentional: is this supposed to be tied to
specific tools as build system are generally tightly coupled? And should we
not change that?
It would help if the PEP had some explanation of the choices made to reserve a
file that partially sets out to replace (all?) other files, but does not do
anything to accomplish that. I realize that PEP-517 defines the API and leaves
the implementation up to the tool, but that doesn't necessarily mean the py-
project file should not name / reserve tables that the PEP 517 API should use.
I'm considering writing a tool that focuses solely on the deployment and
dependency maintenance of a project and would like to not "vendor lock-in" my
users, with even those dependency lists, because I have to use the tool
namespace and can fill it every way I see fit and so will others.
So ideally, we would reserve dependency tables:
[dependencies.$name]
Reserved names: standard, dev, test
Tools can add more names which they can then interpret themselves:
[dependencies.stage]
django-anonymizer = "^0.5"
And test tables and probably one or two more that come to mind. Is there any
interest from the team to improve the file format and lock down such tables?
I'd love to do the initial proposal if that helps move things forward.
--
Melvyn Sopacua