[Distutils] Re: PEP 518 and the pyproject.toml format

On Tue, 11 Sep 2018 at 00:47, Paul Moore wrote:

On Mon, 10 Sep 2018 at 13:12, Melvyn Sopacua wrote:

...

...

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...

Yes, that would sure help any standardization going forward here.

Great. That should keep you busy for a few months to start with :-) Seriously, we've touched on this in the past, and backed away from it because it's so hard to get a common agreement - I can't give specific references, and you may find it hard to locate anything in the archives as it's never really been a topic in its own right, more of a side issue, but don't assume it's straightforward.

The Python Packaging User Guide actually has a survey of "Not a library" packaging options now: https://packaging.python.org/overview/#packaging-python-applications Daniel Holth had a pretty solid proposal years back for extending the wheel file format to cover more use cases: enhance the installation scheme directories to include the various GNU autoconf directories from https://www.gnu.org/prep/standards/html_node/Directory-Variables.html (perhaps with some further amendments enhancements to cope with different conventions on other operating systems). Other than that, the starting point for deployment framework unification work would be to look at what the existing deployment frameworks (such as those mentioned under https://packaging.python.org/overview/#depending-on-a-framework ) take into account, and whether there's something that could be offered at the pyproject.toml level that would better enable portability of projects across different deployment tools. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia