On 08/24/2017 12:22 PM, Nick Coghlan wrote:
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".
My comment was for Platform Python :)
* 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.
No, I don't want to support *full* parallel-installable stacks. Let's
stick to what we currently support in Fedora, not more.
"Python Interoperability Testing Modules" get "x.y" streams and provide
"x.y" binaries; "Python Application Runtime Modules" get one stream for
python3 and one python2, and provide the python2/python3 binaries.
I don't think "Integrated Python Modules" are necessary in Fedora.
Also, the names are a mouthful; let's revise naming after we get the
semantics down :)
- 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.
A shell script that would satisfy file dependencies on "/usr/bin/python"
might not be the best idea.
--
Petr Viktorin
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
