[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions regarding Python packaging
Re: Questions regarding Python packaging
Mon, 28 Jun 2021 22:37:04 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
Am 28.06.21 um 13:59 schrieb Lars-Dominik Braun:*
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.
What should be the use of having a package without pip? Anything else
than saving a few KB?
[setuptools-shim has been removed]
Is this relevant though? I doubt many packages are still importing
distutils and the few that do can be patched.
Was I wrote: This code is still in pip, so I assume it is still relevant.
I don't think patching is a good idea. It requires effort (implementing,
reviewing), which can be saved by keeping exisiting and tested code.
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.
For this case please change the comment not not referring to wheel in
this way. More something like "we expect the builder to support
SOURCE_DATE_EPOCH, like wheel does"
Anyhow, *m not actually convinced that we should throw away the old
code. I can imagine in the next cuple of years quite some new
build-systems to arrive, most of which will most probably not support
SOURCE_DATE_EPOCH in the beginning, and thus making package's life harder.
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
What exaclty do you mean with "flag as broken"? Will anybody (you? ;-)
verify *all* current packages to not be "broken" prior to merging this
Anyhow, again, I'm not convinced we should remove this phase now.
.pth-file are deprecated only, but still supported. By removing this
phase we might create conflict cased we can not foresee. And I would
keep it even if one analyzes none of the current packages is "broken" -
just do be on the save side fpr avoiding user trouble. (These issues
will show up at the user, and are hard to track down, since noone will
think about .pth files)
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
Spread, point 3).
IC. Please add a comment to make this clear (e.g. "handle shebang of
scripts generated by wheel missing leading slash")
I suggest to have phase compile-bytecode still honor older versions
I’m not sure what you mean. compileall is also part of Python 2.
The old code did not compile the source for Python <3.7. Please see the
comment of the old code for rational.
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.)
AFAIK this might not be true if other build systems not using setuptools
at all might show up. And isn't this the main reason for all your work?
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.
Fine, so you can safely remove the respective comment ;-)
| Hartmut Goebel | email@example.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: Questions regarding Python packaging, Hartmut Goebel, 2021/06/22
- Re: Questions regarding Python packaging, (continued)