Add support for PEP-517

[ntninja]

Currently tox does not yet appear have support for the buildsystem.requires key of pyproject.toml as defined in PEP-518.

PIP has implemented this: pypa/pip#4144 (will be part of PIP 10.0) and it would be nice if tox could also add support for installing packages defined using that key, instead of having to use the broken setup_requires key of ./setup.py.

Example of a pyproject.toml file that creates a setuptools 34+ environment:

[build-system]
requires = ["setuptools >= 34", "wheel"]

Example of a pyproject.toml file that creates an environment for building flit packages:

[build-system]
requires = ["flit"]

(Note that this kind of setup is pretty useless without support for PEP-517.)

Approximate step by step algorithm for supporting both PEP-517 and "legacy" ./setup.py deployments (based on PEP-518 & how PIP choose to implement it):

1. If skipsdist in the tox section of tox.ini is true, do nothing
2. Create a new virtualenv to host the sdist generation environment
3. If a file named pyproject.toml exists in the toxinidir:
   1. Parse the pyproject.toml as TOML file (using the python toml library for instance)
   2. Search for the build-system.requires key and treat each entry in the array as an PEP-508 dependency specification
   3. If the key was missing or not an array, report an informative error message and exit
   4. Install each found build dependency into the virtualenv
4. Otherwise install setuptools and wheel into the virtualenv
5. Execute ./setup.py sdist within the virtualenv to generate the sdist used for the subsequent testing steps

(The build environment may be reused between subsequent testing sessions, as long as the list of requirements doesn't change.)

[obestwalter]

Hi @Alexander255, thanks for giving a detailed overview how this could work in tox. I have not yet looked into that topic at all yet and don't even know how many projects are using this. But if pip implements it, it might be a good idea to add it to tox. I don't see this happening for a long time though unless a champion steps up and takes over the implementation.

[ntninja]

don't even know how many projects are using this

Currently, I estimate the number to be around 0 because it's only available in the GIT version of PIP. 🙂

But if pip implements it, it might be a good idea to add it to tox.

Agreed.

I don't see this happening for a long time though unless a champion steps up and takes over the implementation.

I knew you'd say that. 😁 Any pointers where it would make sense to start refactoring to get this into tox?

[obestwalter]

I knew you'd say that. 😁 Any pointers where it would make sense to start refactoring to get this into tox?

I admit that I am a bit on a mission to prioritize on improving process and squashing bugs rather than adding (big) new features in core :)

About your question: I start leaning towards implementing new/experimental functionality like this as plugins. Check the hookspecs - if not everything needed is implemented as a hook I'd rather suggest adding the necessary hooks to core - you can also check the drafts done at the sprint last year about generalizing package builds, as this could have significant overlap: https://github.com/tox-dev/tox/tree/master/doc/drafts

About that toml library: tox is very conservative in pulling in new dependencies and they have to be compatible with all interpreters tox supports. So this would be another reason for implementing this as a plugin. If the toml library only supports Python3 or Python2.7 and above it would be a restriction of the plugin as atm tox still supports 2.6 (but we will drop that shortly after pip does it, which is also happening with the release of 10.0 (pypa/pip#3955)).

[obestwalter]

@Alexander255 I just looked into towncrier for changelog management and your estimate is at least off by one :)

https://github.com/hawkowl/towncrier/blob/master/pyproject.toml

[ntninja]

@obestwalter: Only insofar as that they respect the tool namespace collision avoidance rules of PEP-518:

All other top-level keys and tables are reserved for future use by other PEPs except for the [tool] table. Within that table, tools can have users specify configuration data as long as they use a sub-table within [tool], e.g. the flit tool would store its configuration in [tool.flit].

So one could probably make up an interesting legal case about whether that already entailes "using" PEP-518 or not 😉.

[ntninja]

BTW, I have just tested the Python toml library with Python 2.6 and it (to my great surprise) managed to parse towncrier's pyproject.toml file just fine.

[RonnyPfannschmidt]

@Alexander255 its the toml parser towncrier depends upon https://github.com/hawkowl/towncrier/blob/master/setup.py#L30

[ntninja]

I have now proposed #577 for review and while it doesn't implement PEP-518, it does give us the required building block for doing so: The ability of building sdists in a virtualenv, while being able to specify its dependencies.
The rest is basically just wiring up the information from pyproject.toml correctly.

[obestwalter]

Did you check first how this could be implemented as a plugin?

[takluyver]

TOML libraries: I had a brief look at the code of each a few months back, and at the time I felt more confident in pytoml than in toml. Consequently, pytoml is the one which is vendored into pip, and which will become a dependency of flit once PEP 517 is finalised.

The developer of pytoml did not express great enthusiasm for ongoing maintenance, IIRC. But if it's used in pip, there's an incentive for other people to take over the maintenance if it becomes necessary.

[obestwalter]

Hi @takluyver, thanks for pointing that out. It will be best to have a close eye on the developments in pip and follow their lead then whatever they will use for parsing toml.