help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: program prepared with `guix pack` unusable by end users


From: Wojtek Kosior
Subject: Re: program prepared with `guix pack` unusable by end users
Date: Wed, 26 Oct 2022 09:23:30 +0200

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 <help-guix@gnu.org> 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 -- 
> > <REST-OF-THE-USUAL-GUIX-COMMAND>  
> 
> 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 <zimon.toutoune@gmail.com> wrote:
> 
> > Hi,
> > 
> > On ven., 14 oct. 2022 at 11:09, Wojtek Kosior via <help-guix@gnu.org> 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
> >   
> 
> 


Attachment: pgpqOv2Cg7c43.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]