One minor clarification—Poetry os both an application and a library packaging
tool.
It however relies on the old, non-isolated Setuptools approach to do the
building part
under the hood, so (from my own understanding)
Poetry ≒ Pipenv + Flit - PEP 517 - PEP 518
Whether this is a good approach is another topic (well, I guess my position is
implied as
a Pipenv maintainer), and Paul’s explanation is still complete valid.
> On 10/9, 2018, at 18:47, Paul Moore <p.f.mo...@gmail.com> wrote:
>
> On Mon, 10 Sep 2018 at 10:13, Melvyn Sopacua <m.r.sopa...@gmail.com> wrote:
>
>> First post, so short introduction:
>
> Hi, and welcome.
>
>> 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.
>
> It is true, PEP 518 doesn't define a lot by itself. But as it notes,
> "Tables not specified in this PEP are reserved for future use by other
> PEPs" - in other words, it's possible to add further details, but they
> should be backed by a formal specification, so that tools have a
> common understanding of what to do with the data.
>
>> 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?
>
> Well, poetry isn't (as I understand it) a build system. It doesn't
> define *how* to build a wheel from project sources, rather it
> orchestrates the process of building an application from a set of
> projects (as I understand it from a brief read of the project page).
> That puts it in the same area as pipenv, I guess? That process
> (building *applications*) isn't something that's been really looked at
> yet in terms of standardisation, so yes, it'd still very much fair
> game for something to be discussed and agreed.
>
> One reason this hasn't yet been looked at, as I understand things, is
> that there are a lot of very different scenarios to consider - web
> applications (which I guess are your area of interest), standalone
> command line utilities like Mercurial or the Leo editor, orchestration
> tools like Ansible, background OS service processes, etc. And it's
> unlikely that a "one size fits all" approach would work, so there's a
> whole question of how any standard would establish its scope and
> boundaries. One note of caution - the attempts I've seen in the past
> to define "build processes" tend to promote a certain amount of
> confusion by assuming all projects are similar, and then getting
> bogged down when people with very different requirements come along
> with different assumptions and mistaken expectations.
>
>> 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?
>
> You say "a project (not a library)". I presume by that you mean
> something like the application building process I described above?
> Yes, there's not been any standardisation effort in this area yet, so
> the situation is as you describe. It's not intentional as such, simply
> that no-one has really stepped up to propose anything yet. And maybe
> because there aren't that many formal tools in this area - a lot of
> what goes on appears to be simply workflow and local standards. But
> certainly it's something that might be worth exploring.
>
>> 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.
>
> PEP 518 defines a means of "Specifying Minimum Build System
> Requirements for Python Projects". It defines a new, flexible, file
> format to hold that information, and defers further definition of the
> file contents to future PEPs, but it was never (to my knowledge) a
> goal of that PEP to look at "all other files" and fit them into the
> pyproject.toml format. It did reserve a namespace "tool.XXX" for
> projects that choose to consider themselves as "build tools" - and a
> number of projects (including poetry, I believe) have made use of
> that. (And as you can see, this opens up some confusion over what
> constitutes a "build tool", in contrast to my fairly strict definition
> above).
>
> PEP 517 extended the pyproject.toml format to add data for projects to
> define which build system they want to be used when they are built.
>
> There's nothing yet for "building a project (not a library)". You
> could start with getting agreement on some terminology explaining what
> "a project (not a library)" is, and should be called :-) Would it
> cover pip? What about Mercurial? Ansible? A Django site? A blogging
> application backed by Django (or Flask, or whatever)? Maybe we need
> multiple terms...
>
>> 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.
>
> It does - tools.flit and tools.setuptools, and similar, for other build tools.
>
> Yes, there are places where further standardisation would be good (for
> example, config_options has no defined semantics, which means tools
> like pip can do little beyond pass unmodified key/value pairs to the
> backend), but I don't think that's what you're talking about here. I
> don't think PEP 517 is relevant to your proposal, though (unless you
> expect a tool like poetry to add a PEP 517 backend?)
>
>> 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.
>
> For those tables to *not* lock people into your tool, you'd need other
> tools to agree to use the same names (I assume there *are* other tools
> doing the same as you propose, otherwise there's no potential for
> "lock in" being an issue at this stage ;-)), and for that you'd need a
> standard. That's why PEP 518 has such keys "reserved for future PEPs".
> It's not to block suggestions like yours, but rather to enable them
> (in a way that everyone gets to buy into, rather than the most popular
> tool dictating implementation defined standards).
>
> Paul
> --
> 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/EOFZVUYQAWFEUI653UGKVTBJWVF3BXHP/
--
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/MKTVNO25GHZQ5DKQME2O6HLC2XVGMTWQ/
