On 02/09/2016 08:26 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 08, 2016 at 08:27:53AM +0100, Jan Kurik wrote: >> = Proposed Self Contained Change: System Python = >> https://fedoraproject.org/wiki/Changes/System_Python >> >> Change owner(s): >> * Miro Hrončok <mhroncok AT redhat DOT com> >> * Petr Viktorin >> * Robert Kuska >> * Charalampos Stratakis >> >> Separate several subpackages form the python3 packages - a >> system-python(-libs) that can be required by various tools that >> consider themselves "system tools". > > The part of "Python" that can be usefully split is the standard > library, and that's where most of the size and dependencies come in. > In principle the python binary could be trimmed down, but it's small, > and doesn't bring in any dependencies. The proposal doesn't state it > clearly, so I assume you only want to split the stdlib > (system-python-libs), and providing a separate system-python package > with a separate binary is only a means to differentiate dependencies. Indeed, the Python binary is very small, since it just calls python-libs.* The binary needs to be separate to ensure /usr/bin/python? will always refer to the full installation of Python**, and system-python is there only for things that opt in. > My first issue is that system-python{,-libs} is basically a > subpackage, and should be called python-<something>. python-<something> is also the naming scheme for Python libraries, which this is not. So I don't think the naming is that clear-cut. > And since debian > calls it <something>-minimal, so should we, to match existing > expectations and increase cross-distro similarity. That would also create the expectation that this is following Debian's set of modules for python-minimal. While it's possible that we'll end up with the same set, I don't want to lock us in. > Second, why call it python-*, not python3-*? I think it'll > be endlessly confusing to have both python*- (v3), python2-* (v2), > and python3-* (v3) mixed in the same distro. The assumption is that the basic system tools can agree on a single, system-wide version of Python, and in case of a "Python 4" they can be switched at once. "python-*" is v2, by the way. This change adds "system-python" which is v3. > My third issue is that packages will have a dependency on either > system-python or normal python and this will a binary decision. > Changing the list of things provided by system-python will be hard. > If you add something to system-python, the only way to ensure that > dependent packages can make use of it is to add a versioned dependencies > on system-python. If you remove something from system-python, it will > be necessary to go over all dependent packages and verify if they need > the thing being removed or not. And if users' scripts start using > system-python, it will impossible to remove anything, except maybe > between Fedora releases. This is very inflexible. User scripts should not use system-python. I now think the binary should be at /usr/libexec/system-python, to drive that point home. As for versioned dependencies, and removing things from a published package -- that's how RPMs enerally work. I don't see a problem. > As an alternative proposal, what about using an automatic dependency > generator and having dependent packages require specific modules from > the standard library. Those modules could then be moved between > system-python-libs and python-libs, and things would just work™. I > think that a separate system-python binary also wouldn't be needed. That's a great idea, and I'm thinking along the same lines. But this would have to be done upstream, with the wider Python community on board. Especially with MicroPython gaining popularity, it would be great to split the stdlib into individual chunks, record their interdependencies, and say to library authors: "if you want to opt-in to be compatible with minimal implementations of Python, specify which pieces of stdlib you need, and make sure your dependencies do the same". But, that's quite a long-term project. This Change is relatively small, it should give us the immediate benefits, and if/when the full solution is done it should be easy to switch to it. > The scheme with automatic dependency generation could be implemented > gradually, by introducing the automatic provides and dependencies > generators, without removing current manual provides. Then when the > generated dependencies seem to be right, removing manual dependencies. > > Automatic dependency generation would benefit the whole ecosystem of > Python packages in Fedora. It would. It's also practically impossible to write such generators correctly. (Please prove me wrong!) It's even harder to write such generators for the stdlib than external libraries, because Python's built-in types assume that stdlib there. For example, str.encode() needs the encoding modules, and there's no import statement to analyze. > Zbyszek * this is a simplification -- it also does some decoding now ** also a simplification -- Fedora already splits python3-tests and python3-tkinter out into separate subpackages -- Petr Viktorin -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
