[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52684: [BUG] Multiple Packages Failing to Build
From: |
Christopher Rodriguez |
Subject: |
bug#52684: [BUG] Multiple Packages Failing to Build |
Date: |
Wed, 22 Dec 2021 16:57:52 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Icedove/78.15.0 |
On 12/22/21 3:50 PM, Maxime Devos wrote:
python-build-system doesn't GUIX_PYTHONPATH, because that's the job of
the native-search-paths of python. When a python library is being
built, GUIX_PYTHONPATH is set because the library has python among its
(implicit) inputs. The same holds for profiles: if python and package
containing a lib/pythonVERSION/site-packages are in the same profile,
then GUIX_PYTHONPATH is set in that profile.
I think this is the main issue, here. Installing 'beets' in a profile
doesn't install python, and therefore it doesn't trigger the
GUIX_PYTHONPATH variable. 'beets' still runs because it is referencing a
python in the store, not in the profile, but it can't find plugins that
aren't installed in the core package because the GUIX_PYTHONPATH
environment variable is not being set to point to the directory in the
profile where they are symlinked. Setting this manually to point to
site-packages immediately solves the issue.
There's a reason why we don't ‘just propagate’ like in classical
distros: what if the user installs a version of python incompatible
with the version used by beets?
To avoid such incompatibilities (and other problems), the interpreter
of binaries (and the load path) is hard-coded at built time.
Also, if this is about plugins: adding GUIX_PYTHONPATH to beets'
native-search-paths should work (the wrapper uses 'prefix', not '=').
This is ingenious, and one of the reasons I really love using GNU/Guix.
Such a clever fix to allow the user to really customize their system,
and use their computer the way they want.
The more we discuss this, the more it seems to me that there should
indeed be an environment variable specific to beets, to point to where
the plugins should be linked.
We don't want to bring in python and force a user to decide between
beets and their version of python, but (due to the way the python
plugins are loaded in 'beets') we need to add a pointer to the
site-packages of the python beets is using to run.
Are variables that point to places in the profile allowed? Or do they
have to only point to the store? That would solve the chicken and egg
problem here, where we can't hardcode the directory of the plugin into
'beets' because the plugin is installed afterwards…
--
Christopher Rodriguez
OpenPGP_0x1102102EBE7C3AE4.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
- bug#52684: [BUG] Multiple Packages Failing to Build, (continued)
- bug#52684: [BUG] Multiple Packages Failing to Build, Christopher Rodriguez, 2021/12/21
- bug#52684: [BUG] Multiple Packages Failing to Build, Christopher Rodriguez, 2021/12/21
- bug#52684: [BUG] Multiple Packages Failing to Build, Christopher Rodriguez, 2021/12/22
- bug#52684: [BUG] Multiple Packages Failing to Build, Christopher Rodriguez, 2021/12/22
- bug#52684: [BUG] Multiple Packages Failing to Build, Maxime Devos, 2021/12/22
- bug#52684: [BUG] Multiple Packages Failing to Build, Christopher Rodriguez, 2021/12/27
- bug#52684: [BUG] Multiple Packages Failing to Build, Christopher Rodriguez, 2021/12/27