The Gnome developers are moving towards a Python 3 environment while Apple at least for now remains stuck in Python 2. (WWDC 2018 starts in an hour or so, but even if MacOS 10.14 will finally start distributing Python 3 there’s still several years of supporting older versions ahead of us.)
Several packages in the Gnome stack have dropped autotools support in the last several months in favor of the Meson build system, and the Meson build system requires Python 3. An additional complication is that it’s becoming more common for packages to require Python modules that are distributed primarily or even only via PyPI, e.g. gtk-doc requires Six for Py2/3 compatibility.
So going forward gtk-osx needs a Python 3 and PyPI-friendly environment in which to run. While investigating that yesterday I found https://docs.pipenv.org/. This can be bootstrapped with curl from its Github repo and works with Python2. A pair of configuration files, Pipfile and (poorly named, it's not a lock file) Pipfile.lock, specify the python version and necessary PyPI packages.
I propose that gtk-osx-build-setup.sh would bootstrap Pipenv, install a Pipfile and Pipfile.lock with the requisite dependencies, start up Pipenv, and install jhbuild into the Pipenv environment. One would run jhbuild in a Pipenv shell; that could be made more-or-less transparent with a simple script file or shell alias.
Thoughts?
I've been using Anaconda for this purpose. I would have suggested that, but I took a look at Pipenv (I'd never heard of it before) and it seems more suited to the purpose, since it gets its packages directly from PyPI where everyone publishes them, rather than going through a third-party packager like Anaconda. (I guess that can have pros and cons.)
I've been having a lot of trouble with this and have been unable to build GNOME 3.28 because of it.
Phil,
Yeah, I saw your post on gtk-devel about the meson bugs. I looked at the bug reports and ISTM the solution is that for shell invocation the rpath in the executable just needs to include $PREFIX/lib. That should be doable. The bundler will obviously need to convert @rpath to @executable_path/../Resources/lib as is presently done with absolute paths to $PREFIX, but again that shouldn’t be too much of a problem.
I’ve no doubt that you’ve tried all of that and it didn’t work, so what am I missing?
Note that I haven’t tried any of this yet, including even installing, never mind using, meson. I’m just speculating ATM.
Regards, John Ralls
|
