glib2, glib2-devel, glib2-upstream: only has a build dependency on python?!

[RJVB (René Bertin)]

Working on updating a number of my custom ports (including glib2 and gobject-introspection) I was asked to install a Python port I already had installed. Turned out I install these ports +universal while my Python ports are not for the most part.

As far as I can tell, glib2 does not install a binary that links to a Python binary, nor a binary Python extension. In other words, Python is a build dependency or at best a runtime dependency (but the installed .py files are not executable scripts that require a specific python interpreter).

Either way, the selected Python version should be added to depends_skip_archcheck so +universal glib2 builds do not impose a +universal Python build.

(this also applies to port:gobject-introspection).

[ryandesign (Ryan Carsten Schmidt)]

The dependency was added in [4008d825550f7545a4fdd9f06e3633990ab6c625/macports-ports] by kencu.

[mascguy (Christopher Nielsen)]

Either way, the selected Python version should be added to depends_skip_archcheck so +universal glib2 builds do not impose a +universal Python build.

I've only recently evolved to the point where I understand the need/reasoning behind depends_skip_archcheck, so this (now) makes sense.

Ken/Ryan, any thoughts/concerns with making that change?

[jmroot (Joshua Root)]

glib-genmarshal and several of the other executables installed are python scripts that reference python310 in the shebang, so the dependency type is correct. Using depends_skip_archcheck should be OK if python is only needed for running these scripts.

[RJVB (René Bertin)]

Replying to jmroot:

glib-genmarshal and several of the other executables installed are python scripts that reference python310 in the shebang, so the dependency type is correct.

OK, I missed those.

The proof is in the pudding : force-deactivate python310 and run a rev-upgrade. If that doesn't raise any errors (as I think it will) for port:glib2 python is not a full dependency but a build & runtime dependency only. But maybe there is no practical difference between that combined dependency and a full-on dependency?

(If it does raise errors then depends_skip_archcheck would probably be inappropriate.)

[RJVB (René Bertin)]

FWIW, all scripts and the codegen package work with python2 except forgtester-report (which is deprecated and trivial to patch). IOW, the python dependency could probably have been avoided.

[Christopher Nielsen <mascguy@…>]

In e4dc1e08a821d31b02994d4c2052951ed18f55cf/macports-ports (master):

glib2*: skip archcheck for python
Fixes: #65478

[jmroot (Joshua Root)]

Replying to RJVB:

But maybe there is no practical difference between that combined dependency and a full-on dependency?

There isn't. depends_lib simply means the dependency is needed at both build- and run-time.

[RJVB (René Bertin)]

There could probably be a difference. A runtime dependency could throw a warning instead of an error during a rev-upgrade because they're not necessarily required 100% of the time, or the dependent can handle their absence gracefully. For instance, in this particular case it isn't clear if and when those python scripts are used. Possibly not worth the effort implementing it but in my own ports I'll keep reserving depends_lib for hard, linked-in depencies.

FWIW, the reason I'm triggering on this is that I have the impression I'm flooding my install with python installations, without (AFAIK) a good way to update an entire python x.y "universe" (including all add-on packages) to a newer version. And with the experience that newer versions keep getting a bit slower than the previous one. This is noticeable going from 3.7 to 3.9 for instance, and I'm certain I noticed going to 3.7 too. Python 2.7 remains a lot faster which is a perfect reason for me to keep using it for code that doesn't need the latest version (for features or security considerations).

[mascguy (Christopher Nielsen)]

Replying to RJVB:

FWIW, the reason I'm triggering on this is that I have the impression I'm flooding my install with python installations, without (AFAIK) a good way to update an entire python x.y "universe" (including all add-on packages) to a newer version. And with the experience that newer versions keep getting a bit slower than the previous one. This is noticeable going from 3.7 to 3.9 for instance, and I'm certain I noticed going to 3.7 too. Python 2.7 remains a lot faster which is a perfect reason for me to keep using it for code that doesn't need the latest version (for features or security considerations).

Based on the Python release notes, 3rd-party articles, etc, each Python 3.x release has included performance improvements. And while there may be some past occasions when there was a minor performance reduction - and that doesn't seem common - those were then addressed in a subsequent release.

Meanwhile, Python 3.11 is slated to include significant performance increases, vis-a-vis 3.10:

​https://towardsdatascience.com/python-is-about-to-become-64-faster-python-3-10-vs-python-3-11-benchmark-3a6abcc25b90

Ultimately I'll defer to Josh and others for a more definitive answer. But it's clear that the project - and the industry - has rallied around improving performance in each major Python release. And that's a great thing!

Otherwise, this is somewhat of a pointless discussion: If a given open-source project requires Python for build and/or runtime support, then it is what is is.

The best we can do is validate dependencies for a given port, and remove things when they aren't needed. For example, Josh recently noticed that Python and Perl aren't needed at build time for evolution-data-server, per issue:65409. And that was addressed.

I've also been more cognizant of that in recent months, with much more scrutiny on configure output... combined with extensive use of trace mode.

But at the end of the day, let me pose this question: Is it possible that your perception of Python 3.x being slower with each new release, is simply that... perception? Something to consider.

[RJVB (René Bertin)]

Nope, I've measured it, with actual usually simple apps of the sort that are often written in Python. I know of Python's background so I'm willing to believe that series, complex apps are seeing performance increases. Python is an interpreted language and it's almost inevitable that it gets more sluggish when more features get added, if not only in the initial startup time, which can be a significant part of the total execution time of trivial tasks. For instance, try various time python3.x /opt/local/bin/youtube-dl --help (a few times to get a stable result); I see a continuous increase in execution time from 3.4 to 3.6; 3.7 is a bit slower than 3.4 but faster than 3.5 and 3.9 is maybe a hair faster tham 3.6 . I don't have 3.10 on the machine I'm on.

I think it would be a great idea if the Python PG provided a way to add python variants to ports like this that don't extend Python and can't or don't want to use the system-provided version. Or make a MacPorts "system python" for this purpose, one that that installs into a non-versioned location, or uses a non-versioned site-packages location and that you can keep up to date as you deem fit without leaving a clutter of unused python ports around. Of course there could also have been a single Python3 port which would now be at 3.10.x . I see 3.10 still should work with very old OS X versions, and have there ever been add-ons that didn't work with the newest Python 3 version?

PS: You can see a similar evolution of performance with clang; it's still being tauted as a lot faster than GCC but that is no longer the case at all.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts has long had the practice of using its own ports as dependencies, rather than using the versions of those programs provided by the OS. There have been exceptions to this practice, and over time, those exceptions have proven problematic and have exemplified why we use our own ports instead. Python is the latest example: some ports have made use of /usr/bin/python, but the oldest versions of Mac OS X that MacPorts runs on have such old versions of /usr/bin/python that they are too old in many cases, so many ports have already either used MacPorts python27 unconditionally or have used a condition to use MacPorts python27 on old versions of Mac OS X and /usr/bin/python on newer versions. Some users have objected to being made to install multiple versions of python, especially python27 which is EOL, so when possible we usually choose to use a recommended version of python3x (as specified in the python portgroup) rather than python27. Now that Apple has removed /usr/bin/python as of macOS 12.3 and since /usr/bin/python3 is only available starting in macOS 10.15, it's yet another reason to avoid the use of /usr/bin/python and /usr/bin/python3 entirely, even on systems where it would work, and just always use a MacPorts python port for the sake of consistency of ports across OS versions. I imagine that was Ken's thought process when adding the python3x dependency to this port.

The ticket is closed and any remaining discussions about whether or not ports should be depending on MacPorts python ports, their performance, any improvements that one could make to those ports or the portgroup, the differences between different dependency types and so forth should probably be held in a more-visible location, such as on the macports-dev mailing list.