Re: [gtk-osx-users] Python3

[philip chimento gmail com]

On Mon, Jun 4, 2018 at 7:52 PM John Ralls <jralls ceridwen us> wrote:

On Jun 4, 2018, at 6:13 PM, philip chimento gmail com wrote:

On Mon, Jun 4, 2018 at 4:25 PM John Ralls <jralls ceridwen us> wrote:

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.)

Note that Meson-built libraries are currently mostly broken on macOS because Meson doesn't properly set install_name:
https://github.com/mesonbuild/meson/issues/2121
https://github.com/mesonbuild/meson/issues/3077

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?

Changing the install_name to the absolute installed path with install_name_tool manually does work, but I haven't had time to dig into either a proper solution in Meson, or anything with g-ir-scanner or the bundler. So you are probably not missing anything.

Regards,

Philip C