My problem has been solved. It turned out the Python interpreter contained within the pack was finding an older version of `hydrilla` Python package installed in `~/.local/lib/python3.9/site-packages` and that older version was missing the `console_scripts` entry point that was being loaded. It's worth mentioning that Python interpreter gives `~/.local/lib/python3.9/site-packages` priority over the paths that Guix adds to GUIX_PYTHONPATH. The solution was to patch the wrapper script for each of the commands my package provides. Definition of PYTHONNOUSERSITE enviroment variable stops Python from looking at local site packages. You can see my fix here[1]. I most importantly needed to add the following to #:phases of my package definition > (add-after 'wrap 'prevent-local-package-interference > (lambda* (#:key outputs #:allow-other-keys) > (match-let ((((_ . dir)) outputs)) > (for-each (lambda (prog-name) > (substitute* (string-append dir "/bin/" prog-name) > (("^#!/.*$" shabang) > (string-append shabang > "export PYTHONNOUSERSITE=1\n")))) > '("hydrilla" > "hydrilla-server" > "hydrilla-builder" > "haketilo"))))) It's worth noting that this problem is not exclusive to `guix pack` or to my particular package. Users of other Python programs could in some circumstances experience similar issues. Which makes me think - shouldn't the default behavior be changed? Perhaps by making Python give paths from `GUIX_PYTHONPATH` priority over those in user site packages directory? Should I report this as a bug to bug-guix@gnu.org? Best, Wojtek [1] https://git.koszko.org/pydrilla/commit/?h=koszko&id=f7c4dff95e88d58d61c51b2a6b94c90e2e4e0c4b -- (sig_start) website: https://koszko.org/koszko.html PGP: https://koszko.org/key.gpg fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A Meet Kraków saints! #17: blessed Jolenta Helena Poznaj świętych krakowskich! #17: błogosławiona Jolenta Helena https://pl.wikipedia.org/wiki/Jolenta_Helena -- (sig_end) On Mon, 17 Oct 2022 15:36:48 +0200 Wojtek Kosior via wrote: > Hello again after a break, > > > Well, then I tried to reproduce your failure in order to understand what > > is going wrong but I hit this: > > > > [...] > > > > That’s because your package ’python-pyopenssl-for-haketilo’ inherit from > > ’python-pyopenssl’ defined in (gnu packages python-crypto). The issue > > is that the ’origin’ also inherits > > > > (origin > > (inherit (package-source base)) > > > > and thus > > > > (patches (search-patches "python2-pyopenssl-openssl-compat.patch")))) > > > > does not make sense anymore because this patch is against 21.0.0 and > > your variant is about 22.0.0. > > Thank you for your time spent on trying this out. > > The error is surely a result of us using different Guix versions. In the > version I had the pyOpenSSL version was 20.0.1 and no patch was being > used yet[1]. > > Another user also had problems building from source under a different > Guix version. I knew this would happen but I didn't have a ready > solution before. I now came up with a Makefile that organizes most > common development tasks in my project into rules that call `guix > time-machine` under the hood[2]. This should be a general solution for > this kind of problems. > > > Well, further investigations about what could be wrong for “guix pack” > > needs a way to reproduce. :-) Could you fix or point a working > > example in your Git repository? > > As for troubleshooting the creation of Hydrilla 3.0-beta1 pack, one can > get the same enviroment I was using by pulling Guix from commit > fd00ac7e27c8a6d4b4d4719b4f8797bdce204623. Although most list users here > probably know how to achieve this, I'm putting this here for convenience > > > guix time-machine --commit=fd00ac7e27c8a6d4b4d4719b4f8797bdce204623 -- > > Anyway, the main problem could probably be also troubleshooted by > experimenting with the pack I made available[3] as it is also the one > that is known to have caused problems. > > Thank you again, > Wojtek > > [1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-crypto.scm?id=fd00ac7e27c8a6d4b4d4719b4f8797bdce204623#n650 > [2] https://git.koszko.org/pydrilla/commit/?h=koszko&id=ed2e14dd6ced4f64b6ac707c5998b38a78e6d7ad > [3] https://hydrillabugs.koszko.org/projects/haketilo/wiki/Releases#Files > > -- (sig_start) > website: https://koszko.org/koszko.html > PGP: https://koszko.org/key.gpg > fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A > > Meet Kraków saints! #13: blessed Jan Beyzym > Poznaj świętych krakowskich! #13: błogosławiony Jan Beyzym > https://pl.wikipedia.org/wiki/Jan_Beyzym > -- (sig_end) > > > On Fri, 14 Oct 2022 13:00:18 +0200 > zimoun wrote: > > > Hi, > > > > On ven., 14 oct. 2022 at 11:09, Wojtek Kosior via wrote: > > > > > I accidently just replied to you, Simon, instead of making a "reply > > > all". I'm reposting the same now, sorry for the nuisance... > > > > Do not worry. :-) > > > > > So, I did run `guix shell -L. hydrilla`. First, I got a warning about > > > > > >> ambiguous package specification `hydrilla' > > > > That’s expected because: > > > > --8<---------------cut here---------------start------------->8--- > > (define-public hydrilla > > (package > > (name "hydrilla") > > > > [...] > > > > (define-public hydrilla-dist-tarball > > (let ((base hydrilla) > > (filename (string-append "hydrilla-" %hydrilla-version ".tar.gz"))) > > (package > > (inherit base) > > (source (local-file > > --8<---------------cut here---------------end--------------->8--- > > > > It means that the package ’hydrilla’ has the name “hydrilla” and because > > the package ’hydrilla-dist-tarball’ inherits then it also has the name > > “hydrilla”. Idem for the version field. > > > > Therefore, > > > > guix shell -L . hydrilla > > > > refers to 2 possible packages. All Guix CLI commands use “name“ and > > “version” for looking up to packages and not the symbols. > > > > > > Well, then I tried to reproduce your failure in order to understand what > > is going wrong but I hit this: > > > > --8<---------------cut here---------------start------------->8--- > > $ guix build -L . python-pyopenssl@22.0.0 > > The following derivations will be built: > > /gnu/store/gyc6sw8a9vq09z6p7plv3k5sjjvrcz9i-python-pyopenssl-22.0.0.drv > > /gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv > > building /gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv... > > pyOpenSSL-22.0.0/ > > > > [...] > > > > pyOpenSSL-22.0.0/tox.ini > > patching file src/OpenSSL/SSL.py > > Hunk #1 FAILED at 1421. > > Hunk #2 FAILED at 2449. > > 2 out of 2 hunks FAILED -- saving rejects to file src/OpenSSL/SSL.py.rej > > patching file tests/test_ssl.py > > Hunk #1 FAILED at 1928. > > 1 out of 1 hunk FAILED -- saving rejects to file tests/test_ssl.py.rej > > source is at 'pyOpenSSL-22.0.0' > > applying '/gnu/store/4cd1x970w3jg3rwaiqg174x56mvkihij-python2-pyopenssl-openssl-compat.patch'... > > Backtrace: > > > > [...] > > > > ERROR: > > 1. &invoke-error: > > program: "/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-patch-2.7.6/bin/patch" > > arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" "/gnu/store/4cd1x970w3jg3rwaiqg174x56mvkihij-python2-pyopenssl-openssl-compat.patch") > > > > [...] > > > > builder for `/gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv' failed with exit code 1 > > build of /gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv failed > > View build log at '/var/log/guix/drvs/rf/awn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv.gz'. > > cannot build derivation `/gnu/store/gyc6sw8a9vq09z6p7plv3k5sjjvrcz9i-python-pyopenssl-22.0.0.drv': 1 dependencies couldn't be built > > guix build: error: build of `/gnu/store/gyc6sw8a9vq09z6p7plv3k5sjjvrcz9i-python-pyopenssl-22.0.0.drv' failed > > --8<---------------cut here---------------end--------------->8--- > > > > That’s because your package ’python-pyopenssl-for-haketilo’ inherit from > > ’python-pyopenssl’ defined in (gnu packages python-crypto). The issue > > is that the ’origin’ also inherits > > > > (origin > > (inherit (package-source base)) > > > > and thus > > > > (patches (search-patches "python2-pyopenssl-openssl-compat.patch")))) > > > > does not make sense anymore because this patch is against 21.0.0 and > > your variant is about 22.0.0. > > > > > > Well, further investigations about what could be wrong for “guix pack” > > needs a way to reproduce. :-) Could you fix or point a working example > > in your Git repository? > > > > > > Thanks, > > simon > > > >