PEP 518 and the future of custom or directly invoked commands?

[pganssle]

I think the current trajectory of setuptools is that we're deprecating direct invocation of most if not all custom commands, and as such the PEP 518 support is moving entirely to pip. This is fine for install and wheel and presumably build and several other commands will also be implemented in pip, while test is switching over to pytest and upload is switching over to twine.

However, people have long been able to write custom commands and have integrated them into their workflow, so they invoke python setup.py lint or python setup.py clean or something. What are we planning on doing for all of those?

My $0.02 is that I think we can't realistically get rid of these (and, frankly, I'm not sure we want to), but invocation via setup.py is a non-starter because the dependencies really have to happen before the script is invoked.

As such, I suggest that we create a new entry point script distributed with setuptools, like pysetup. This would be a thin wrapper around python setup.py that is PEP 518-aware. It would install the required dependencies in an isolated build environment and could even address #1201 with a [tool.setup] section of pyproject.toml.

CC: @jaraco @dstufft @benoit-pierre @di @pradyunsg @pfmoore

[pfmoore]

I think what's likely needed is a standalone "build environment" library that handles the common task of creating a PEP 517 style isolated build environment (note that it's PEP 517 that discusses isolated builds, rather than PEP 518 - although as this issue proves, it's not something that's limited to PEP 517 implementations...)

The https://github.com/pypa/pep517 project includes a build environment abstraction that might be useful here. Alternatively, pip's own build isolation code might be something we could split out (or merge with the pep517 library).

Build isolation code in pip has proved quite tricky to get right, so it's definitely something that's worth doing once and sharing among projects :-)

[pganssle]

@pfmoore I think the question of how the isolated build environment is implemented is important (and I agree that a standalone library for building it would make this much easier to implement), but we may want to start by determining whether having a command line script that is just a PEP 518-aware version of invoking python setup.py is a good idea in the first place.

[pfmoore]

Sure - that's not something I have much of an opinion on, though, so I'll defer to others on that point :-)

What I will say is that IMO that's purely a setuptools question. The whole point of PEP 518 and 517 is to decouple tools like pip from build backends like setuptools, so that pip only interacts with setuptools via a very narrowly defined interface (PEP 517). So anything outside of that is specific to setuptools. In much the same way as flit has its own commands (flit init and similar), setuptools can do the same. Making the interface to such commands be a new setuptools front-end command seems a reasonable idea to me, but how it'd work in practice is going to be something for the project to thrash out (I imagine explaining why python setup.py mycommand no longer "works right" will be the biggest stumbling block here).

PS Is there any reason why the tool can't just be called setuptools? As a parallel to flit, setuptools test seems like a reasonable command - and it avoids stealing the pysetup name, which might be something a new Python build backend might like to use ;-)

[pganssle]

PS Is there any reason why the tool can't just be called setuptools? As a parallel to flit, setuptools test seems like a reasonable command - and it avoids stealing the pysetup name, which might be something a new Python build backend might like to use ;-)

No reason, for whatever reason I just thought it seemed weird to call it that. Let's assume the command is called setuptools from here on out.

(I imagine explaining why python setup.py mycommand no longer "works right" will be the biggest stumbling block here).

That's kinda already the problem, except right now we have to say, "Well don't use setup.py unless you have to, and if you want install or bdist_wheel use pip, if you want upload or register use twine, etc, etc". At least if we have a command line app we can say, "You should no longer directly invoke setup.py, but you can use setuptools <cmd> and it will work just like it did before, but now all that stuff that was broken can actually be fixed!"

[jaraco]

In jaraco/pip-run#33, I've started exploring if our existing tooling might already support the need.

pip-run provides isolated build environments and if pip supported installing of pyproject.toml files, then invocation of any setuptools command could be as simple as:

$ pip-run -r ./pyproject.toml -- setup.py my_command

It's not quite as elegant as setuptools my_command, but close. Given that these use-cases are largely deprecated anyway, perhaps having a slighly clumsy syntax is a good thing. I'm not proposing necessarily that this be the recommended solution, but I did want to share it for illustration purposes.