GNU bug report logs - #35322
AM_PATH_PYTHON incompatible with Python frameworks on macOS

Previous Next

Package: automake;

Reported by: Chih-Hsuan Yen <yan12125 <at> gmail.com>

Date: Fri, 19 Apr 2019 15:40:02 UTC

Severity: normal

Tags: confirmed, help

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Joshua Root <jmr <at> macports.org>
To: Karl Berry <karl <at> freefriends.org>, yan12125 <at> gmail.com
Cc: 35322 <at> debbugs.gnu.org
Subject: bug#35322: AM_PATH_PYTHON incompatible with Python frameworks on macOS
Date: Mon, 15 Feb 2021 14:10:21 +1100
On 2021-2-15 09:16 , Karl Berry wrote:
> Unfortunately, simply removing the change to the `base' assignment as
> you did in your change, for instance the first hunk,
> 
> -    sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
> +    sitedir = sysconfig.get_path('purelib')
> 
> will affect any use of AM_PATH_PYTHON in an (it seems to me)
> incompatible way. That does not seem viable. It's not even OS-dependent,
> since other Mac users might not use --enable-framework.
> 
> Evidently the current default for am_py_prefix is analogous to how
> Automake treats "lispdir" and others, to make for a coherent system. So
> it's not desirable to change these variables' default values in a
> system-dependent way.

A python installation configured with --disable-framework will have a 
different value for base. I guess it's a question of whether the goal is 
installing modules in a consistent location across different systems, or 
installing them somewhere where the python on this system will be able 
to find them.

The documentation says that pythondir is "The directory name for the 
site-packages subdirectory of the standard Python install tree." I 
suppose that could be interpreted different ways depending on your 
chosen value of "standard". Bear in mind that macOS may be unique in 
that it's normal for python's sys.prefix to be different (a few 
subdirectories deeper) than the --prefix passed to a configure script. I 
do wonder if the current approach was designed with the assumption that 
they would always be the same.

> I don't know enough about Python to know if there is some clever way to
> handle this. In my naive way, it seems like you just have to override
> the directory for your case. I think setting the shell variable
> $am_cv_python_pythondir before running configure would do this, although
> I confess I haven't tried it.

Just to be clear, --enable-framework is not just the default for 
MacPorts, it's the default on macOS in general in all recent python 
versions. It's how the Mac binary installers from python.org are 
configured. Python won't be able to find modules installed in the 
location currently chosen by AM_PATH_PYTHON unless its configuration is 
changed to look there.

I admit I seem not to totally understand the design here based on what 
you've said above, but it seems like it would be better to have defaults 
that result in a working installation.

- Josh




This bug report was last modified 4 years and 57 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.