From: Lars-Dominik Braun <lars@6xq.net>
To: Hartmut Goebel <h.goebel@crazy-compilers.com>
Cc: guix-devel@gnu.org, 46848@debbugs.gnu.org
Subject: Re: Questions regarding Python packaging
Date: Mon, 28 Jun 2021 13:59:31 +0200 [thread overview]
Message-ID: <YNm5oxRelWX1LyWM@noor.fritz.box> (raw)
In-Reply-To: <520a5492-6467-bbfc-3252-f17a5cc5d16f@crazy-compilers.com>
Hi Hartmut,
> sorry for being late for commenting on this (the time I can spend on
> guix is rather limited atm).
no problem, same thing on my side.
> *
>
> Not installing pip by default might break some user's environments.
> Anyhow, since using pip in guix is not such a good idea anyway, this
> should be okay.
True. We could rename python→python-minimal-interpreteronly (or similar;
given that python-minimal already exists) and python-toolchain→python to
work around that.
> *
>
> "use-setuptools" is gone. There are still about 10 packages with
> "#:use-setuptools #f" - which means they are (expected to be)
> incompatible with setuptools for some reason. You might want to
> check whether these packages actually still can't be packages with
> setuptools.
Yeah, I’ve seen those, but the number was too small to bother for now.
I’ll have a look later.
> *
>
> setuptools-shim has been removed. I don't think this is a good idea,
> since this peace of code enforces packages to be actually build with
> setuptools instead of old distutils. This code is still in current
> pip, so I assume it is still required.
>
> (This shim ensures setuptools is used, even if setup.py only imports
> distutils. And setuptools is required for some options like
> ""--single-version-externally-managed" - as the comment for the shim
> says.)
Is this relevant though? I doubt many packages are still importing
distutils and the few that do can be patched.
> *
>
> set-SOURCE-DATE-EPOCH: Please keep the verbose rational. It's much
> more helpful than the new one-line comment.
You mean the one from the now-removed ensure-no-mtimes-pre-1980? Sure.
> *
>
> set-SOURCE-DATE-EPOCH: This implementation makes the code depend on
> wheel and wheel being used for installation.
Technically it depends on the wheel builder understanding
SOURCE_DATE_EPOCH (not necessarily python-wheel). I’d say that’s
acceptable and it’d be preferable to fix build systems not respecting
this variable imo.
> *
>
> Why has rename-pth-file been removed? Are you sure .pth-files are
> never created anymore nowerdays?
Given that easy-install has been deprecated I think it’s safe to remove
this phase and flag any packages creating this easy-install.pth as
broken. (There are, however, legitimate packages creating files like
ruamel.yaml-0.15.83-py3.8-nspkg.pth.)
> *
>
> python-hashbang: Isn't this done already by the normal
> "patch-shebangs" phase after install in gnu-build-system? (BTW:
> these are called *she*bangs).
Afaik the function patch-shebang expects a leading slash and thus it
does not replace this “special” shebang (see
https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl;
Spread, point 3).
> *
>
> I suggest to have phase compile-bytecode still honor older versions
> of python
I’m not sure what you mean. compileall is also part of Python 2.
> pypa bulld is where the PyPA is pushing towards. Anyhow, as of today, as
> far as I can see, adoption is low.
Of pypa build? That is true.
> AFAIK fhere is no standard way for running tests in python. pytest seems
> to be the most modern test-system. Anyhow packages still use nose or tox
> (which again might run pytest or nose, with parameters fetched from
> tox.ini). So I'm afraid, there is no general rule.
>
> Did the PyPA publish some recommendations or PEP on this?
I’m not aware of any accepted PEP’s. There is a discussion about the
removal of `python setup.py test`:
https://github.com/pypa/setuptools/issues/931
And a proposal for pyproject.toml going nowhere:
https://discuss.python.org/t/proposal-for-tests-entry-point-in-pyproject-toml/2077/2
> As I Python developer I nowerdays would expect pip and venv (which is
> part of the std-lib - but not the virualenv, which is a separate module)
> to be availalbe when installing "python". Anyhow I could live with pip
> being a separate package.
If we keep setuptools/pip bundled, we don’t have to do any of this
pypa-build dance. We could also modernize python-build-system around
`pip install` and just be done with it. (I don’t have a proof-of-concept
for that yet.)
> "python-toolchain" sounds oversized for me. Would this include the
> C-compiler, too (which one? maybe I want to build cross). I'd rather not
> have such a package.
See suggestion above wrt renaming.
> The gnu-build-system already provides the "unzip" binary (used in phase
> "unpack"). So we could simply use this. Otherwise I recommend using the
> Python zip module, as this is what is used for creating the zip-archives
> :-)
I’m using Python’s zipfile module already.
Cheers,
Lars
next prev parent reply other threads:[~2021-06-28 12:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-08 14:27 Questions regarding Python packaging Tanguy Le Carrour
2020-11-08 17:05 ` Leo Famulari
2020-11-10 8:35 ` Tanguy Le Carrour
2020-11-08 20:43 ` Michael Rohleder
2020-11-10 8:30 ` Tanguy Le Carrour
2020-11-09 16:54 ` Hartmut Goebel
2020-11-10 8:47 ` Tanguy Le Carrour
2020-11-10 8:53 ` Hartmut Goebel
2021-01-05 10:25 ` Lars-Dominik Braun
2021-01-06 15:32 ` Tanguy LE CARROUR
2021-01-22 8:38 ` Tanguy LE CARROUR
2021-01-23 12:34 ` Lars-Dominik Braun
2021-01-24 13:30 ` Tanguy LE CARROUR
2021-01-24 20:54 ` Ryan Prior
2021-01-25 11:47 ` Lars-Dominik Braun
2021-01-25 16:57 ` Ryan Prior
2021-02-05 10:40 ` Hartmut Goebel
2021-05-17 6:24 ` Lars-Dominik Braun
2021-06-06 16:44 ` Tanguy LE CARROUR
2021-06-06 19:44 ` Lars-Dominik Braun
2021-06-22 6:53 ` Removal of Python 2? Hartmut Goebel
2021-06-22 12:41 ` Konrad Hinsen
2021-06-23 15:26 ` Ludovic Courtès
2021-06-23 15:34 ` zimoun
2021-06-23 18:32 ` Konrad Hinsen
2021-06-22 18:02 ` Ryan Prior
2021-06-25 6:37 ` Konrad Hinsen
2021-06-22 7:00 ` Questions regarding Python packaging Hartmut Goebel
2021-06-28 11:59 ` Lars-Dominik Braun [this message]
2021-06-28 20:37 ` Hartmut Goebel
2021-06-29 7:20 ` Lars-Dominik Braun
2021-07-06 12:16 ` [bug#46848] " Lars-Dominik Braun
2021-07-07 15:01 ` Hartmut Goebel
2021-01-26 7:21 ` Tanguy LE CARROUR
2021-01-27 3:43 ` Maxim Cournoyer
2021-01-06 15:37 ` Tanguy LE CARROUR
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=YNm5oxRelWX1LyWM@noor.fritz.box \
--to=lars@6xq.net \
--cc=46848@debbugs.gnu.org \
--cc=guix-devel@gnu.org \
--cc=h.goebel@crazy-compilers.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).