On Sun, 26 May 2019 at 23:22, Paul Moore <p.f.mo...@gmail.com> wrote: > > On Sun, 26 May 2019 at 13:59, Bernat Gabor <gaborjber...@gmail.com> wrote: > > > > It will exist only as a legacy thing, and as setuptools build system > > configuration. PEP-517 and PEP-518 defines what pip will support going > > forward. > > To be more specific, the "setuptools setup.py install" command will be > supported for as long as the setuptools project chooses to support it. > However, the packaging standards, and specifically pip, are moving > away from directly installing on target systems, to a model where the > "build the project" and "install the project" steps are separate, with > wheels being the intermediate. So projects that cannot be installed by > building a wheel and then installing that wheel (which is basically an > unpack operation, there are no custom install-time steps supported) > will no longer be supported by standard tools and will have to rely on > custom install commands.
I'd qualify Paul's last point here by restricting it to standard tools that target *platform independent* installation, which includes pip. The core assumption is that if an operation doesn't make sense when installing into a virtual environment inside a user's home directory without elevated privileges, then the standard installation commands won't support that, as at that point you've moved beyond "please install this Python module into this Python interpreter environment" and on to "please install this software application onto my computer", which is an activity we're explicitly declaring to be out of scope for the standard Python-level installation tooling. Windows and Mac OS X folks are used to that distinction (see the notes on platform specific PyInstaller features in https://www.pyinstaller.org/features.html ), but it's historically been less critical on Linux systems, as just adding extra custom code to setup.py was a sufficient solution. We don't know yet what the full consequences of that change in policy are going to be. Part of the solution will likely be tools like BeeWare's briefcase ( https://github.com/beeware/briefcase ), which aims to automatically produce native platform installers for GUI applications that can be installed as Python projects. However, part of it will also hopefully be development of a separate post-installation protocol, whereby an already installed Python package can be instructed to execute additional system integration operations that don't get executed when installing into a virtual environment. Then tools like PyInstaller, briefcase, pyp2rpm, Debian's pybuild helper, etc could potentially consume that extra information to determine which commands to run after the base install to run the extra platform integration steps. I'm not aware of anyone specifically working on that problem yet, though, so it's wide open to anyone that thinks it sounds like a potentially interesting API design project. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/7BKCCRZEKYYNOZZJNLX3RZGTCB5MLKDY/
