unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: Phil <phil@beadling.co.uk>
Cc: help-guix@gnu.org
Subject: Re: No Explicit Python Version Dependency In Package Definitions?
Date: Mon, 04 Jan 2021 23:51:26 +0000	[thread overview]
Message-ID: <87h7nwjm69.fsf@cbaines.net> (raw)
In-Reply-To: <85lfd8qnuv.fsf@beadling.co.uk>

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]


Phil <phil@beadling.co.uk> writes:

> Hi,
>
> It seems standard not to declare python2 or python3 as a dependency on
> python package definitions - however other dependent python libraries are stated.
>
> eg python-scipy will declare dependencies on python-numpy and
> python-matplotlib - but not on a specific version of python package
> required to use it.
>
> I'm guessing this is to avoid tying packages to specific python
> releases, but I'm curious about the mechanics.

Build systems are a mechanic to deduplicate common steps, but also
common inputs between packages, and the python-build-system will include
a default Python as an input.

https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/python.scm#n138

> It looks like 'package-with-python2' might be used to allow us to
> distinguish between python2 and python3, but ignoring the python2 case,
> I have the following python3 questions:
>
> Can we can install python-scipy without installing python3, given python
> isn't an explicit dependency in the package?

Guix packages don't have dependencies like other package managers,
there's propagated-inputs which can act like dependencies where Guix
will attempt to add propagated inputs to the profile when you install a
package. But generally "dependencies" as in other things you should have
when you have a given store item, are just references between store
items:

→ guix gc --references /gnu/store/jj1915czcy6wlf6riajapl1j6dfgwwii-python-scipy-1.3.2
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib
/gnu/store/741057r2x06zwg6zcmqmdyv51spm6n9i-gfortran-7.5.0-lib
/gnu/store/bs9pl1f805ins80xaf4s3n35a0x2lyq3-openblas-0.3.9
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31
/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2
/gnu/store/jj1915czcy6wlf6riajapl1j6dfgwwii-python-scipy-1.3.2
/gnu/store/jxx8fr78jrcvpid5aplmkplbm1dk6czs-python-3.8.2

→ grep -r jxx8fr78jrcvpid5aplmkplbm1dk6czs /gnu/store/jj1915czcy6wlf6riajapl1j6dfgwwii-python-scipy-1.3.2
Binary file /gnu/store/jj1915czcy6wlf6riajapl1j6dfgwwii-python-scipy-1.3.2/lib/python3.8/site-packages/scipy/optimize/_zeros.cpython-38-x86_64-linux-gnu.so matches
...

So, you can't have this particular python-scipy output in your store
without python as well, as it's referenced by some shared libraries,
which I guess makes sense.

> Which site-packages directory under what python3 version will be used?
> A quick check looks that /path/to/profile/lib/python3.8/site-packages is
> currently used but what makes the decision to put them under python3.8 -
> especially if python3.8 isn't installed in the profile?

The python build system takes care of where files end up in the package
outputs at least:

https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/python-build-system.scm#n38

> What happens if Guix upgrades python3 from 3.8 -> 3.9?  How are packages
> already installed under the 3.8, moved to the new 3.9 python version, is this seamless?

When the default python version is changed, the build system will change
accordingly.

> If I'm using Guix on top of a foreign distro and don't have python3
> installed as part of Guix, will my python-scipy end-up installed for my
> foreign distro's python install?

Installing Guix things is just ensuring things are in the /gnu/store,
plus maybe some environment variables for the profile. So it won't end
up where your (not Guix) distro installs Python things at least.

Hope that helps!

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

  reply	other threads:[~2021-01-04 23:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04 23:34 No Explicit Python Version Dependency In Package Definitions? Phil
2021-01-04 23:51 ` Christopher Baines [this message]
2021-01-05 14:59   ` Phil
2021-01-05 21:46     ` Christopher Baines
2021-01-05 22:56     ` Ricardo Wurmus

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=87h7nwjm69.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=help-guix@gnu.org \
    --cc=phil@beadling.co.uk \
    /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).