unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Rodriguez <yewscion@gmail.com>
To: 52684@debbugs.gnu.org
Subject: bug#52684: [BUG] Multiple Packages Failing to Build
Date: Wed, 22 Dec 2021 16:57:52 -0500	[thread overview]
Message-ID: <afa00a66-ff77-4aac-7907-57637684fb35@gmail.com> (raw)
In-Reply-To: <f47f537125eb943f34912d00386db8baf028eb44.camel@telenet.be>


[-- Attachment #1.1.1: Type: text/plain, Size: 2395 bytes --]



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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4045 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  parent reply	other threads:[~2021-12-22 21:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 19:17 bug#52684: [BUG] Multiple Packages Failing to Build Christopher Rodriguez
2021-12-21  0:36 ` zimoun
2021-12-21 17:52 ` Christopher Rodriguez
2021-12-21 18:02   ` Maxime Devos
2021-12-21 18:08     ` Christopher Rodriguez
2021-12-21 19:47 ` Christopher Rodriguez
2021-12-21 20:44   ` Maxime Devos
2021-12-21 21:38 ` Christopher Rodriguez
2021-12-21 22:38   ` Maxime Devos
2021-12-22 17:07 ` Christopher Rodriguez
2021-12-22 17:36   ` Maxime Devos
2021-12-22 19:59 ` Christopher Rodriguez
2021-12-22 20:50   ` Maxime Devos
2021-12-22 20:54     ` Maxime Devos
2021-12-22 21:57     ` Christopher Rodriguez [this message]
2021-12-23  9:27       ` Maxime Devos
2021-12-22 20:53   ` Maxime Devos
2021-12-27 18:18 ` Christopher Rodriguez
2021-12-27 20:06   ` Maxime Devos
2021-12-30 10:20   ` Maxime Devos
2021-12-30 10:29   ` Maxime Devos
2021-12-27 20:36 ` Christopher Rodriguez
2022-01-02 13:53 ` Christopher Rodriguez
2022-06-23  0:58 ` bug#52684: [PATCH v1] Updated and fixed frotz package Christopher Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afa00a66-ff77-4aac-7907-57637684fb35@gmail.com \
    --to=yewscion@gmail.com \
    --cc=52684@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).