On 24 August 2017 at 19:02, Petr Viktorin <pvikt...@redhat.com> wrote: > On 08/24/2017 10:13 AM, Nick Coghlan wrote: >> 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) > > Stream names match the Platform module. We follow its policy here, even when > it changes.
Oh, interesting, I had that backwards (I thought the planned F27 Python modules were the ones named after upstream Python releases). That means the current module definitions would be closer to what I'm calling the "Integrated Python Modules". >> * 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 > > These need to be parallel installable, to support tox. So we need separate > modules for each Python release. Aye, I agree that will be a good way to tackle the parallel installable versions that *don't* define "/usr/bin/python3". However, for containers designed to run Python applications (web or otherwise), we *will* want mutually conflicting streams that define their symlinks and RPM provides based only on the Python major version. So lets make those extra modules their own distinct category: * Python Interoperability Testing Modules - one module per Python X.Y release - only one stream per module - conflict with the corresponding Application Runtime stream - provide "/usr/bin/pythonXY" and "/usr/bin/pythonX.Y" - do NOT satisfy "python2-*" and "python3-*" RPM dependencies And looking at their current implementation in Fedora, one notable difference between them and the Application Runtime streams is that these would just use their bundled pip and setuptools, rather than splitting those out the way the regular packages do. >> - stream names match Fedora releases (f26, f27, etc) >> - each depends on an *exact* version of the corresponding Python >> Application Runtime module > > > Huh? You just said Python Application Runtime Modules would conflict with > this. Sorry about that - when I started writing the email, my plan was to have them conflict with each other, but as I wrote that initial version up I went "Hang on, couldn't I use a stream dependency here and rely on *that* to trigger a conflict if you had an Integrated Python module installed and then tried to switch to an unsupported runtime stream, or vice-versa?" >> * Default Python Module >> - provides /usr/bin/python (and nothing else) >> - stream names: no-default, python3-default, python2-default > > +1 > I guess this would contain a "python" RPM, containing just a /usr/bin/python > symlink, which would added to non-modular Fedora as well. Pretty much, yeah. The "no-default" stream would be a bit different, as in that case it would install a shell script that printed out a custom error message. 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
