WIll custom setup.py with (set library-prefix have post install actions) continue to be supported ?
I'm making a python package for something python Gedit/Pluma/Xed plugin. Like other lots of other packages that use Gtk, I use glib-compile-schemas [1] at install time. I do this by using a custom setup.py- similar to this file this from flux: https://github.com/xflux-gui/fluxgui/blob/master/setup.py#L81(other app, like Meld to something similar) It looks like there are a lot of changes happening to setuptools, will this continue to work or will it break one day ? This isn't the only file I'd like to generate at install time, but might be the hardest to work around if I can't. The other custom action I'm going looking at is setting `--install-lib` to the editors plugin directory (this varies depending on: Operating system and is the user root ?) I'm using use pip for this, as the install story for most python plugins for these editors is nonexistant - people have to copy the files to some place manually, and instructions usually miss out Windows and OSX. [1] glib-compile-schemas takes an XML file and generates a binary GVariant file.
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. On Sun, May 26, 2019, 15:25 Stuart Axon via Distutils-SIG < distutils-sig@python.org> wrote:
I'm making a python package for something python Gedit/Pluma/Xed plugin.
Like other lots of other packages that use Gtk, I use glib-compile-schemas [1] at install time.
I do this by using a custom setup.py - similar to this file this from flux: https://github.com/xflux-gui/fluxgui/blob/master/setup.py#L81 (other app, like Meld to something similar)
It looks like there are a lot of changes happening to setuptools, will this continue to work or will it break one day ?
This isn't the only file I'd like to generate at install time, but might be the hardest to work around if I can't.
The other custom action I'm going looking at is setting `--install-lib` to the editors plugin directory (this varies depending on: Operating system and is the user root ?)
I'm using use pip for this, as the install story for most python plugins for these editors is nonexistant - people have to copy the files to some place manually, and instructions usually miss out Windows and OSX.
[1] glib-compile-schemas takes an XML file and generates a binary GVariant file. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/EWR4X...
On Sun, 26 May 2019 at 13:59, Bernat Gabor <gaborjbernat@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 hope this clarifies things. Paul
On Sun, 26 May 2019 at 23:22, Paul Moore <p.f.moore@gmail.com> wrote:
On Sun, 26 May 2019 at 13:59, Bernat Gabor <gaborjbernat@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 | ncoghlan@gmail.com | Brisbane, Australia
On Sun, May 26, 2019 at 12:24:08PM +0000, Stuart Axon via Distutils-SIG wrote:
I'm making a python package for something python Gedit/Pluma/Xed plugin.
Like other lots of other packages that use Gtk, I use glib-compile-schemas [1] at install time.
I do this by using a custom setup.py - similar to this file this from flux: [1]https://github.com/xflux-gui/fluxgui/blob/master/setup.py#L81 (other app, like Meld to something similar)
It looks like there are a lot of changes happening to setuptools, will this continue to work or will it break one day ?
This isn't the only file I'd like to generate at install time, but might be the hardest to work around if I can't.
For gtimelog I ended up calling glib-compile-schemas at runtime, prior to `import gi`. I'm also setting os.environ['GSETTINGS_SCHEMA_DIR'] to the directory where my schema file resides (inside the virtualenv's site-packages, usually). This allows me to support 'pip install gtinelog', as well as running straight from a git checkout with no intermediate build step. Marius Gedminas -- We have enough youth, how about a fountain of SMART?
participants (5)
-
Bernat Gabor -
Marius Gedminas -
Nick Coghlan -
Paul Moore -
Stuart Axon