Created attachment 351299 [details] [review]
build: fix the path to python3 for mesonscripts/post_install.py

What kind of system would we want to run gnome-clocks in that doesn't have python3 installed system-wide?

This problem was found on FreeBSD and python was installed system-wide with packages. The problem is that many *BSD systems use two prefixes: /usr is reserved for the base system. Packages are not considered part of the operating system, so they are installed into /usr/local, /usr/pkg or other user-chosen prefixes. Python is not included in the base system, so it cannot be installed into /usr.

Created attachment 365999 [details] [review]
build: fix the path to python3 for build-aux/post-install.py

I still don't like these changes.

Debian automatically rewrites the shebangs for packaged Python scripts to have them work consistently and appropriately for Debian. (The GNOME Tweaks shebang on Debian is /usr/bin/python3 ).

Why can't BSD do that too if they're going to have an unusual system?

I do not think it's right for whatever version of Python a user has locally installed to be used to run GNOME Tweaks. I want the system Python 3 only to be used.

(In reply to Jeremy Bicha from comment #5)
> I still don't like these changes.
> 
> Debian automatically rewrites the shebangs for packaged Python scripts to
> have them work consistently and appropriately for Debian. (The GNOME Tweaks
> shebang on Debian is /usr/bin/python3 ).

Using absolute path in shebangs of packaged scripts is correct and recommended. FreeBSD does do the same thing, so the shebang of gnome-tweak-tool on FreeBSD is /usr/local/bin/python2.7. (FreeBSD still uses GNOME 3.18 so it is python2)

However, I think the rule of using hard-coded path only applies to files provided by distributions. We cannot expect all distributions to install python3 to the same path, and the only portable absolute paths are /bin/sh and /usr/bin/env. The proper way of hard-coding paths of interpreters into scripts is to use '#!@PYTHON@' in shebangs and ask the build system to replace them with the path it find. You only rely on PATH to find python3 at build time. After the package is installed, it becomes an absolute path specific to a distribution so users cannot change it with PATH. Thus, we follow the recommendation of distributions without hard-coding non-portable paths in sources.

> 
> Why can't BSD do that too if they're going to have an unusual system?
> 

I think the problem is not 'why we cannot do' but 'why we have to do'. Yes, FreeBSD ports has the ability to patch shebangs by setting one variable in Makefile. It can even patch outdated configure or libtool scripts to fix common problems by setting a variable. However, if users decide to build software from sources by themselves, they will wonder why they cannot build it while the version in FreeBSD ports can be built successfully without any patch files.

I use JHBuild to build GNOME directly from upstream git repositories in order to catch problems early. I think it is good to reduce the number of downstream patches, so everything can be tested easily.

> I do not think it's right for whatever version of Python a user has locally
> installed to be used to run GNOME Tweaks. I want the system Python 3 only to
> be used.

build-aux/post-install.py is not an installed script. It is only used during 'ninja install'. It is not something users can use after installation is done. Since we are required to rely on PATH to find python3 during 'configure' and 'build' phases, I don't know why we cannot use '#!/usr/bin/env python3' in a script used for installation. build-aux/post-install.py is not gnome-tweak-tool and it should never be packaged.

Oh, I'm not the GNOME Clocks maintainer. I didn't read my bug mail closely enough to see that this wasn't for GNOME Tweaks, so never mind.

I do not have strong objections, but I guess my question is: what does meson do? meson itself is written in python so we should do the same.

Also, is there a way to ask meson to run these kind of scripts with the same interpreter used to run meson itself?

(In reply to Paolo Borelli from comment #8)
> I do not have strong objections, but I guess my question is: what does meson
> do? meson itself is written in python so we should do the same.
> 

meson.py in the source repository uses '#!/usr/bin/env python3'. meson installed on the system uses the absolute path to python used to run 'setup.py'.

For example, on FreeBSD, if I install meson with 'python3 setup.py install', the shebang of the installed meson script is '#!/usr/local/bin/python3'. If I install it with 'python3.6 setup.py install', the shabang is '#!/usr/local/bin/python3.6'.

> Also, is there a way to ask meson to run these kind of scripts with the same
> interpreter used to run meson itself?

Meson has a module called 'Python 3', so I think we can do it this way:

python3 = import('python3')
meson.add_install_script(python3.find_python().path(),
  join_paths(meson.source_root(), 'build-aux', 'post-install.py'))

sounds good

Created attachment 366213 [details] [review]
build: Use python3 found by meson to run build-aux/post-install.py

Review of attachment 366213 [details] [review]:

If it is tested, sure, go ahead. Thanks!

Can you do the same for baobab?

Yes, I attached a new patch to baobab.

Attachment 366213 [details] pushed as 6541a87 - build: Use python3 found by meson to run build-aux/post-install.py