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: Csepp
Subject: Re: program prepared with `guix pack` unusable by end users
Date: Wed, 26 Oct 2022 21:55:58 +0200

Wojtek Kosior via <help-guix@gnu.org> writes:

> [[PGP Signed Part:Undecided]]
> 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
>> >   
>> 
>> 
>
>
> [[End of PGP Signed Part]]

IMHO yes, the pack output does not work as expected.  That's the
definition of a bug.



reply via email to

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