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

--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/54QFJKANZOXY6NQZKEAPG346OL7MCQCV/

Reply via email to