On 09. 06. 21 13:47, Matthias Klose wrote:
On 6/8/21 3:14 PM, Petr Viktorin wrote:
On 04. 06. 21 16:17, Matthias Klose wrote:
Earlier this year, somebody pointed out that it might be worthwhile to
coordinate around package names used in distros, and in this case proposing a
python3-full package. The idea is to have some common names used across
distributions which can be used to tell users and developers what to install for
the full Python experience. That could become just some documentation, or an
informal PEP.
Today, every distributions splits the upstream CPython source into multiple
binary packages, mostly into runtime, development, documentation packages, and
maybe packages with seldom used dependencies like Tcl/Tk.
For the upcoming Debian release, I have created a python3-full package, which
depends on all binary packages built from the CPython source package, so people
can install everything using 'apt install python3-full'. I didn't create
something like a python3-full-dev package. Note that the name python3-full is
provisional for now, and I'm happy to change it to anything that we can come up
with. One thing I would like to avoid is to re-purpose any other existing name
for a meta/dependency package name, as this would have consequences for
dependencies in a Linux distribution, requires some cycles to change, and isn't
that easy to backport to older releases than any new package name.
One more thing that came up when preparing the "Draft PEP: Graceful cooperation
between external and Python package managers", there maybe should be a
meta-package which also includes dependencies on pip and pipx. Pip usually
comes with the binary CPython installers for MacOS and Windows, so it might make
sense to define such a meta package for Posix bases distros as well.
pip seems reasonable, since it's distributed with CPython upstream; pipx feels
like it should be a different package.
noted. The motivation about pipx is, that it creates and installs into a venv by
default. But there's also talk by the pip maintainers to merge or integrate
that functionality into pip.
Currently my proposal for a python3-full package would consist of
- the complete standard library (what is inside Lib and Modules)
All that are built on the platform.
For example, if a distro removes NIS libraries for security reasons, the `nis`
module won't show up in python3-full. (But it could be added in a third-party
repo.)
ok, maybe we should even mention stuff that is optional for python3-full? Why
not build the nis module into a separate binary package, or are the build
dependencies not available in Fedora?
But yes, it's a good idea to mention all the extensions which might not be built
by default, where the CPython build still succeeds.
I don't think there should be a cross-distro standard with the exact
list. If a distro cannot or doesn't want to build a module, a list isn't
likely to stop it, anyway.
- all development files
- all documentation files (if built locally)
- the complete testsuite
- dependencies on required system dependencies, which are not
itself shared libaries:
- tzdata
- media-types
- ca-certificates? Not sure if that is needed
- dependencies on the wheel files shipped with the distro. At
least for Debian, I cannot use ones provided in CPython,
because they are not built from source. The wheel files built
from the setuptools and pip packages are used instead.
The python3-full package currently doesn't depend on any compiler packages (gcc,
gfortran), or build tools like make.
Right. For those and things like sqlite3-devel, it's more reasonable to ask the
distro for the Python package's build-time dependences.
Any thoughts on this proposal?
I don't see an issue with adding the package in Fedora.
ok, let's clarify the status about the nis extension, and probably others.
Matthias
_______________________________________________
Linux-sig mailing list -- linux-sig@python.org
To unsubscribe send an email to linux-sig-le...@python.org
https://mail.python.org/mailman3/lists/linux-sig.python.org/
Member address: arch...@mail-archive.com
