From: Edouard Klein <edou@rdklein.fr>
To: Kyle Andrews <kyle@posteo.net>
Cc: help-guix@gnu.org
Subject: Re: Using an alternative python to build python modules
Date: Tue, 21 Feb 2023 17:50:23 +0100 [thread overview]
Message-ID: <878rgrhs3z.fsf@rdklein.fr> (raw)
In-Reply-To: <87y1orzz16.fsf@posteo.net>
Hi !
I am not an expert, and your question definitively is in somewhat new
territory to me, if a real expert comes by, listen to them instead. From
what I gather, transitive inputs are only directs inputs and then
propagated inputs (from the docstring of the package-transitive-inputs
func).
However, package-input-rewriting, as per the doc:
replaces its direct and indirect dependencies, including implicit inputs
when deep? is true, according to replacements
I'm not sure of the precise meaning of indirect dependencies, but I
would expect the Python interpreter to be one of them (and also the
compiler that would build this interpreter, for example).
Therefore, adding #:deep #t may suffice.
However, Simon's solution with package-with-explicit-python looks more
appropriate to me.
Reading its source, I see that python packages have a #:python package
argument, so in the package definition of python-apted, adding
(arguments
`(#:python ,your-old-python))
my be enough, but that is just a guess and if I were you I'd try simon's
snippet first.
Good luck,
Cheers,
Edouard
Kyle Andrews <kyle@posteo.net> writes:
> Dear Edouard and Wojtek,
>
> Thank you very much for your generous suggestions!
>
> I would like to give you an update to share the state of my still
> incomplete understanding after thinking about them.
>
> With regards to this sort of thing:
>
> ```
> (package-input-rewriting/spec
> `(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)))))
> ```
>
>
> I did not try this yet because I don't understand it yet. My confusion
> stems from the fact that python is not in the transitive inputs of any
> python package.
>
> ```
> (use-modules (gnu packages) (gnu packages python))
> ,pretty-print (package-transitive-inputs python)
> ```
>
> How could modifying the graph have any effect?
>
> Instead I tried to go down the package-with-python2 route since it APTED
> claimed it was tested on python 2.7. Unfortunately, I ran into many
> other errors where different python packages in the transitive inputs of
> python-numpy failed because they were using various python 3 syntaxes.
>
> Now I am trying to figure out how to best go about trying with python 3
> instead. One issue I am not sure how to get around is the
> python?-variant property convention. It is not clear to me how to write
> one for an inferior python for use with
> `package-with-explicit-python'.
>
> I will keep you posted if I make any breakthroughs. I'm really eager to
> be able to replace conda with guix.
>
> Best Regards,
> Kyle
>
> Edouard Klein <edou@rdklein.fr> writes:
>
>> As an example in this line of thought, a long time ago I submitted a
>> patch (since then reverted as it broke a lot of things) to use an
>> obsolete version of a python module, which was the only one that worked
>> with a specific module that hadn't updated its dependencies:
>>
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=32ba87c14fd5e5b54d95211cd9a159d568ce7c67
>>
>> Look at the following lines:
>>
>> #+begin_src scheme
>> (define-public prompt-toolkit-2-instead-of-prompt-toolkit
>> (package-input-rewriting/spec
>> `(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)))))
>> #+end_src
>>
>> If instead of replacing "python-prompt-toolkit" with
>> python-prompt-toolkit-2, you could replace "python" with the version of
>> python you want to use, package-input-rewriting would then handle the
>> work of changing the python package anywhere it appears in any
>> dependency of your manifest.
>>
>> You can then end your manifest with
>> (python-3.6-instead-of-python python-apted)
>>
>> Cheers,
>>
>> Edouard.
>>
>>
>> Wojtek Kosior via <help-guix@gnu.org> writes:
>>
>>> [[PGP Signed Part:Undecided]]
>>> Hi Kyle,
>>>
>>> Have you looked at the (package-input-rewriting) procedure described
>>> towards the bottom of "Defining Package Variants"[1]?
>>>
>>> You might also like to look at the not-exported
>>> (package-with-explicit-python) proc defined in
>>> guix/build-system/python.scm[2]. It is used to produce python2 variants
>>> of packages but I suppose it would also work for swapping the minor
>>> versions of python3.
>>>
>>> Good luck with your task :)
>>>
>>> Wojtek
>>>
>>> [1] https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html
>>> [2] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/python.scm?id=b544f460989a6189af111bb3ff6752cabdf23abc#n82
>>>
>>> -- (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
>>>
>>> ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
>>> ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
>>> -- (sig_end)
>>>
>>>
>>> On Fri, 17 Feb 2023 21:27:39 +0000
>>> Kyle Andrews <kyle@posteo.net> wrote:
>>>
>>>> Dear Guix,
>>>>
>>>> I want to use the python-apted package in my manifest. That package is
>>>> not in Guix, but can readily be fetched from:
>>>>
>>>> ```
>>>> guix import pypi APTED > python-apted.scm
>>>> ```
>>>>
>>>> I just had to prefix the following modules to turn that into a package
>>>> definition as well as a manifest.
>>>>
>>>> ```
>>>> (use-modules (guix packages)
>>>> (guix download)
>>>> (guix licenses)
>>>> (guix profiles)
>>>> (gnu packages)
>>>> (guix build-system python))
>>>> ```
>>>>
>>>> During my original testing of my scientific workflow I discovered that
>>>> there was a bug introduced to the APTED package which was caused by a
>>>> change in how python worked under the hood. As a result, the APTED
>>>> package only advertises compatibility with python versions less than
>>>> 3.7. So, I would like to use python 3.6 to be on the safe side.
>>>>
>>>> I also want to include 60+ other packages in my manifest which are
>>>> "current" with the Guix repository and included within it. For
>>>> situations like this it would be really convenient if it were possible
>>>> to pass a version of python to python-build-system. Then, I hope all I
>>>> would have to do is pass another another defined variant of the python
>>>> package (e.g. called python-3.6) into that build-system argument.
>>>>
>>>> For example:
>>>>
>>>> ```
>>>> (build-system python-build-system #:python python-3.6)
>>>> ```
>>>>
>>>> That would be quite convenient and in line with the level of complexity
>>>> I was faced with when I took the conda approach before trying to use
>>>> Guix. Unfortunately, this functionality doesn't seem to be provided out
>>>> of box and I am seeking help in the hopes that there is an easy way to
>>>> do it.
>>>>
>>>> Am I thinking about this right?
>>>>
>>>> Thanks,
>>>> Kyle
>>>>
>>>> P.S.
>>>>
>>>> APTED claims to also be able to run on top of python-2.7 so maybe that
>>>> fact could be used to simplify this specific issue. I just wanted to
>>>> discuss the general problem first because I really want Guix to gain
>>>> broad traction within the scientific community.
>>>>
>>>> P.P.S.
>>>>
>>>> Here is a pretend manifest where I would love guidance on how to make
>>>> python-apted get built in the context of python-2.7 or ideally
>>>> python-3.6 even though the latest version of python is python-3.9 (where
>>>> APTED doesn't always work).
>>>>
>>>> ```
>>>> (use-modules (guix packages)
>>>> (guix download)
>>>> (guix licenses)
>>>> (guix profiles)
>>>> (gnu packages)
>>>> (guix build-system python))
>>>>
>>>> (define-public python-apted
>>>> (package
>>>> (name "python-apted")
>>>> (version "1.0.3")
>>>> (source (origin
>>>> (method url-fetch)
>>>> (uri (pypi-uri "apted" version))
>>>> (sha256
>>>> (base32
>>>> "1sawf6s5c64fgnliwy5w5yxliq2fc215m6alisl7yiflwa0m3ymy"))))
>>>> (build-system python-build-system)
>>>> (arguments '(#:tests? #f))
>>>> (home-page "https://github.com/JoaoFelipe/apted")
>>>> (synopsis "APTED algorithm for the Tree Edit Distance")
>>>> (description "APTED algorithm for the Tree Edit Distance")
>>>> (license expat)))
>>>>
>>>> (concatenate-manifests
>>>> (list (specifications->manifest (list "r" "r-dplyr" "r-reticulate"))
>>>> (packages->manifest (list python-apted))))
>>>> ```
>>>>
>>>
>>>
>>> [[End of PGP Signed Part]]
next prev parent reply other threads:[~2023-02-21 17:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 21:27 Using an alternative python to build python modules Kyle Andrews
2023-02-18 9:57 ` Wojtek Kosior via
2023-02-18 17:53 ` Edouard Klein
2023-02-20 22:29 ` Kyle Andrews
2023-02-21 16:50 ` Edouard Klein [this message]
2023-02-21 12:52 ` Simon Tournier
2023-02-21 20:26 ` Kyle Andrews
2023-02-21 21:10 ` Simon Tournier
2023-02-22 9:23 ` Simon Tournier
2023-02-21 21:28 ` Kyle Andrews
2023-02-22 4:23 ` Kyle Andrews
2023-02-22 10:09 ` Simon Tournier
2023-02-24 0:16 ` Kyle Andrews
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=878rgrhs3z.fsf@rdklein.fr \
--to=edou@rdklein.fr \
--cc=help-guix@gnu.org \
--cc=kyle@posteo.net \
/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.
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).