GNOME Bugzilla – Bug 680138
pygobject should be installable using pip
Last modified: 2016-06-23 21:24:06 UTC
Most Python developers expect to be able to install packages by using "pip install package", and having that work also means that you can declare dependencies in other packages, so that "pip install myapplication" will automatically install pygobject. $ pip install pygobject Downloading/unpacking pygobject Downloading pygobject-2.28.3.tar.bz2 (889Kb): 889Kb downloaded Running setup.py egg_info for package pygobject ******************************************************************** * Building PyGObject using distutils is only supported on windows. * * To build PyGObject in a supported way, read the INSTALL file. * ******************************************************************** Complete output from command python setup.py egg_info: ******************************************************************** * Building PyGObject using distutils is only supported on windows. * * To build PyGObject in a supported way, read the INSTALL file. * ********************************************************************
IMO, no. Every linux distribution has a dependency resolution system (the package manager). Linux users should use that. We don't even have a PyGObject + g-i for windows to distribute, doing so via pip is getting ahead of ourselves. Don't even get me started on the clusterf**k that is easy_install/setuptools/distribute/2/pip/virtualenv/packaging
Dropping the autoconf bits and only building through distutils is not realistically going to happen. The current autotools based build system is not exactly easy, and with distutils it would probably become five times bigger. That said, if someone wants to go ahead and work on a patch for this, I'm happy to review it, but I won't have time to work on this myself.
FWIW, those interested in packaging python extensions, particularly non-trivial ones that use native code, should read http://mail.python.org/pipermail/python-dev/2012-June/120430.html (in particular those posts by David Cournapeau)
(In reply to comment #1) > We don't even have a PyGObject + g-i for windows to distribute, doing so via > pip is getting ahead of ourselves. Agreed. Let's not forget the intent of PyGObject (on any OS) is to enable writing applications targeting the GNOME platform in Python and not the other way round (integrating GNOME into Python). For developers on win32, there will eventually be an SDK (recently discussed on gtk-devel-list). Distributing apps for end users should probably be done with py2exe or somesuch tool. (In reply to comment #2) > Dropping the autoconf bits and only building through distutils is not > realistically going to happen. The current autotools based build system is not > exactly easy, and with distutils it would probably become five times bigger. > > That said, if someone wants to go ahead and work on a patch for this, I'm happy > to review it, but I won't have time to work on this myself. A distutils based setup.py used to exist in addition to the usual autotoolery, but I removed it for PyGObject 3 because: - nobody had shown any interest in building PyGObject/PyGTK with msvc for years - the autotoolery got patched to work for MinGW/MSYS which where the only reasons setup.py existed in the first place. Relevant commit: http://git.gnome.org/browse/pygobject/commit/?id=8d3125c8ce9890c70400dd8a3ac273b590fe6a31
I think there's an easier way around this, that is to include the egg-info files so that pip can detect that PyGObject is actually installed, so it doesn't have to download it manually. That said, if you want to install a package depending on PyGObject on a linux based distribution without having installed PyObject you're pretty much out of luck. Summary: * Yes, we want to support pip install foobarapp that depend on pygobject * No, we will not switch to using autotools * We should install the relevant egg-info files so pip can detect which pygobject version is installed
Created attachment 225579 [details] [review] Install an .egg-info file This will help easy_install and pip to figure out that PyGObject is already installed.
Created attachment 225580 [details] [review] Install an .egg-info file This will help easy_install and pip to figure out that PyGObject is already installed.
Created attachment 225581 [details] [review] Install an .egg-info file This will help easy_install and pip to figure out that PyGObject is already installed. An updated version which uninstalls and includes the python version and platform in the filename as well.
(In reply to comment #5) [..] > * No, we will not switch to using autotools to *stop* using autotools.
Comment on attachment 225581 [details] [review] Install an .egg-info file Thanks for this! I applied it, I think it's appropriate for 3.4.1.
We won't realistically go beyond this "already installed" check, so closing.
*** Bug 708542 has been marked as a duplicate of this bug. ***
This is really regrettable. The internet is filled with documentation instructing devs to stop using using PyGTK and move to gi. But the installer for Windows was a long time comming, and the support for many python developers favorite way of settings up development environment (virtual env and pip) is a WONTFIX. GTK is quick moving from being a versatile, multiplatform GUI toolkit, to a GNOME only technology, which is a pity.
On a cheerier note. What about a script to install gi inside a virtual env using jhbuild? Would that be an acceptable solution?