On 21 August 2017 at 19:46, Petr Viktorin <pvikt...@redhat.com> wrote: > On 08/18/2017 01:38 PM, Nick Coghlan wrote: >> Does that approach sound sufficiently plausible to folks that I can >> use it to provide feedback to the folks working on the modularity >> tooling as to the capabilities we think we'll need? > > That sounds like it would work. But yes, please talk to the Modularity WG to > see if modules can be made to work that way.
Aye, this draft proposal was essentially me figuring out what I think we're going to want/need for Python before I pitched the related feature ideas to the Modularity WG :) The proposal then became something I could point to to say "This is the problem I'm trying to solve" while we discussed various possible ways of solving it. I finally had a discussion with Langdon about it today, and he really isn't a fan of my idea of trying to enhance the modularity tooling to natively support parallel installation of streams - he'd strongly prefer that we stick to the idea of "one active stream per module per system" (at least for now), and then rely on separate SRPMs and/or the Software Collections parallel installation layout to handle use cases like tox. (Note: I'll get the properly formatted proposal updated by tomorrow, so feel free to wait for that if the email version below is a bit hard to read) My current thinking based on that discussion is that we're actually going to need a module set that looks like this for F28+: * Platform Python (already planned for F27) - part of the Platform module - stream names match Fedora releases (f26, f27, etc) * Python Application Runtime Modules (already planned for F27) - one module for Python 2 and one for Python 3 - stream names match upstream Python releases (2.7, 3.6, etc) - Application Runtime Modules conflict with the corresponding Integrated Python Module - provide "/usr/bin/python2" and "/usr/bin/python3" respectively - also satisfy "python2-*" and "python3-*" RPM dependencies - only the Python 2 module satisfies "python-*" RPM dependencies (for now) * Integrated Python Modules - one module for Python 2 and one for Python 3 - stream names match Fedora releases (f26, f27, etc) - each depends on an *exact* version of the corresponding Python Application Runtime module * Default Python Module - provides /usr/bin/python (and nothing else) - stream names: no-default, python3-default, python2-default The scope for F27 would specifically be Platform Python and the Python Application Runtime Modules, with the separate Integrated Python Modules being defined for F28+ At least for now, the Python XY stacks for Fedora and EPEL, as well as the Python SCLs, would be treated as something generated downstream from the app runtime modules, rather than as something that the modularity tooling would necessarily handle natively. The general idea is that it would then be up to other modules to decide whether they specifically needed the Integrated Python Module with all the related system bindings (in which case they'd either depend on that module, or depend on another RPM that depended on it), or were prepared to cope with any installed version of Python 3 (in which case they'd just use normal RPM level "python3*" dependencies). Right now, the difference between the Integrated Python Modules and the Python Application Runtime Modules isn't particularly obvious, but it hopefully becomes clearer once we consider questions like "Who will decide when to rebase to Python 3.7?" and "When will a particular stream stop being updated?". For the Integrated Python Modules, those are Fedora level design decisions, as reflected in the stream names being based on Fedora versions. This means that for a system container, or a traditional mutable installation, you'd be able to continue to rely on a shared Python installation with all the operating system level bindings for things like the RPM database, without Fedora package maintainers having to provide prebuilt bindings for arbitrary Python versions. You'd only change streams when you changed base Fedora versions, and the update cycle for these streams would match the Fedora release cycle (i.e. each stream would receive updates for 13 months from the date of the corresponding Fedora release). By contrast, for the Python App Runtime Modules, when to rebase is an application developer level decision, as reflected in the stream names being based directly on Python versions. This means that for an application container image, you'd be able to select an arbitrary Python version of your choice, but in doing so, you'd potentially be giving up ready access to pre-built bindings for various system APIs (if your choice of stream didn't match the dependencies declared in the Integrated Python Module). For these streams, the update cycle would match that of the relevant upstream Python branch (i.e. full maintenance updates until shortly after the next Python feature release, then security updates until 5 years after the original X.Y.0 release). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
