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