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 12:07:51 -0500 [thread overview]
Message-ID: <e9017a4d-784f-b338-b360-b66fc14a4fbc@gmail.com> (raw)
In-Reply-To: <7ee7ed76-4676-6c86-87f0-8d7ab886fc50@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 3680 bytes --]
So, I took some time to do some digging this morning, and I now have a
few results and a few more questions.
First, I tried `guix shell --pure python beets beets-bandcamp` to ensure
that the plugin would be detected once `GUIX_PYTHONPATH` was set as You
had mentioned. That did work, though the environment did not have
`python-isodate`, which the plugin complained was missing. If this is
the case, should python-isodate then be a progagated input, since it is
apparently required at runtime? Or is there a difference w/r/t the
`--pure` environment that won't be present on an actual install?
Second, I ran `cat $(which beet)` on my currently installed `beets`
package for the `PYTHON_PATH` that is currently being set. It has a lot
of entries, all like the following:
`/gnu/store/8df74df68i14lfjsny07x7cq6ffn0fs5-beets-1.5.0/lib/python3.8/site-packages:/gnu/store/nc3rprg62sigx8s9ps02wb8zbaz8qzl3-python-flask-1.1.2/lib/python3.8/site-packages`.
I'm currently diving each of these packages to see how I might add code
to set `beets-bandcamp` to add to this list, though I wonder if that is
actually possible, since the plugin will usually be installed after the
root program. Is this path pulled from a global location, or is it
determined at install time?
Third, I did try pulling
```scheme
(native-search-paths
(list (guix-pythonpath-search-path)))
```
into the `beets` definition, but that brought a *lot* of other
dependencies in. Same with using
```scheme
(native-inputs
`(("sitecustomize.py" ,(local-file (search-auxiliary-file
"python/sitecustomize.py")))))
```
Sorry if I am missing something obvious, here. I will keep looking, just
wanted to log what I've tried so far.
Once I figure out how search paths actually work inside of `guix`, I'm
sure the solution will be fairly simple. But I haven't quite gotten
there yet.
It seems like the solution has to do with `wrap-package`, but looking at
the `beets` package definition, I only see the following lines related
to wrapping the binary:
```scheme
;; Wrap the executable, so it can find python-gi (aka
;; pygobject) and gstreamer plugins.
(add-after 'wrap 'wrap-typelib
(lambda* (#:key outputs #:allow-other-keys)
(let ((prog (string-append (assoc-ref outputs "out")
"/bin/beet"))
(plugins (getenv "GST_PLUGIN_SYSTEM_PATH"))
(types (getenv "GI_TYPELIB_PATH")))
(wrap-program prog
`("GST_PLUGIN_SYSTEM_PATH" ":" prefix (,plugins))
`("GI_TYPELIB_PATH" ":" prefix (,types)))
#t))))))
```
It doesn't seem like PYTHONPATH is being interacted with here. Is that
something that might be defined elsewhere? I'm tempted to merge in the
following, which I pulled from another package (solfege), to explicitly
set PYTHONPATH… But I don't want to change something if it is set elsewhere.
```scheme
(add-after 'install 'wrap-program
(lambda* (#:key inputs outputs #:allow-other-keys)
;; Make sure 'solfege' runs with the correct PYTHONPATH.
(let* ((out (assoc-ref outputs "out"))
(path (getenv "GUIX_PYTHONPATH")))
(wrap-program (string-append out "/bin/solfege")
`("GUIX_PYTHONPATH" ":" prefix (,path))))
#t)))))
```
Any input or clarification will be appreciated! I'm learning a lot as I
(slowly) work through this! Thank You for Your time!
[-- 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 --]
next prev parent reply other threads:[~2021-12-22 17:09 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 [this message]
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
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=e9017a4d-784f-b338-b360-b66fc14a4fbc@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).