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

Reply via email to