[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.
- Re: program prepared with `guix pack` unusable by end users, Wojtek Kosior, 2022/10/13
- Re: program prepared with `guix pack` unusable by end users, (, 2022/10/13
- Re: program prepared with `guix pack` unusable by end users, zimoun, 2022/10/14
- Re: program prepared with `guix pack` unusable by end users, Wojtek Kosior, 2022/10/14
- Re: program prepared with `guix pack` unusable by end users, zimoun, 2022/10/14
- Re: program prepared with `guix pack` unusable by end users, Wojtek Kosior, 2022/10/17
- Re: program prepared with `guix pack` unusable by end users, Wojtek Kosior, 2022/10/26
- Re: program prepared with `guix pack` unusable by end users,
Csepp <=
- Re: program prepared with `guix pack` unusable by end users, Maxim Cournoyer, 2022/10/27
- Re: program prepared with `guix pack` unusable by end users, Wojtek Kosior, 2022/10/27
- Re: program prepared with `guix pack` unusable by end users, Maxim Cournoyer, 2022/10/28