unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Edouard Klein <edou@rdklein.fr>
To: Wojtek Kosior <koszko@koszko.org>
Cc: Kyle Andrews <kyle@posteo.net>, help-guix@gnu.org
Subject: Re: Using an alternative python to build python modules
Date: Sat, 18 Feb 2023 18:53:18 +0100	[thread overview]
Message-ID: <871qmmlut8.fsf@rdklein.fr> (raw)
In-Reply-To: <20230218105734.61c02d5e.koszko@koszko.org>

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]]


  reply	other threads:[~2023-02-18 17:59 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 [this message]
2023-02-20 22:29     ` Kyle Andrews
2023-02-21 16:50       ` Edouard Klein
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=871qmmlut8.fsf@rdklein.fr \
    --to=edou@rdklein.fr \
    --cc=help-guix@gnu.org \
    --cc=koszko@koszko.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).