On 08/25/2017 10:23 AM, Nick Coghlan wrote:
On 24 August 2017 at 21:28, Petr Viktorin <pvikt...@redhat.com> wrote:
On 08/24/2017 12:22 PM, Nick Coghlan wrote:
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 :)
Oops, reading comprehension fail on my part :)
* 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;
These modules will probably only have one stream each, so I don't have
a strong personal opinion on what that stream is called (although it's
also possible they could each end up with two streams: one that
actually installs the parallel installable version, and one that just
depends on the corresponding application runtime stream).
"Python Application Runtime Modules" get one stream for
python3 and one python2, and provide the python2/python3 binaries.
I think we can do better than that, and the relative timing of the F28
and Python 3.7 releases provides a good illustration of why I think we
should aim to do so:
* F28 code freeze is in March, with the release in May
* 3.7 release candidate is in May, with the release in June
Traditionally, that would have meant that we wouldn't get a Fedora
based Python 3.7 container out the door until the release of Fedora 29
in October, and we'd never ship the F28+3.7 combination at all, even
for folks that mainly just want the Python runtime, and then will use
pip to install everything else they need.
Traditionally, that's very well possible: there'd be a "python37"
package that provides a /usr/bin/python37. We do the same for old
versions, and for python36 on f25. It works quite well.
If the intended use for 3.7 in f28 is to make a virtualenv and use pip
to install things, that virtualenv can very well be made by calling
/usr/bin/python37. I still see no reason for a stream that makes
/usr/bin/python3 point to 3.7.
However, I think modularity gives us access to a more flexible
approach: we can set up the F28 System Profile to *default* to the 3.6
Python App Runtime stream, allowing the sequence of updates to be:
1. In Fedora 28, we split the Python 3 runtime module into two pieces:
- the App Runtime, with a 3.6 stream
- the Integrated Runtime, with an f28 stream that depends on AppRuntime:3.6
2. After 3.7 hits beta in January 2018, we add a "3.7" stream to the App Runtime
3. After 3.7 is released, we start building a new F28+3.7 app
development container
- in this configuration, most system packages that need Python 3 can't
be installed
How do you achieve this for package that depend on /usr/bin/python3?
4. In Fedora 29, we add an f29 stream to the integrated runtime that
depends on AppRuntime:3.7
- now it would be the F29+3.6 configuration that prevents use of
system packages that need Py3
I don't think "Integrated Python Modules" are necessary in Fedora.
Whether they're necessary or not depends on whether we enable the
F28+3.7 configuration: if we allow that, then we need a way to make it
clear that in that configuration, the only Python-3-based system
packages you can install are the ones that rely on
/usr/libexec/platform-python instead of /usr/bin/python3 (since the
others ran their integration testing against the default 3.6 stack).
The only thing that relies on /usr/libexec/platform-python is dnf.
Nothing else.
Also, the names are a mouthful; let's revise naming after we get the
semantics down :)
I'm reasonably happy with App Runtime (since I stole that directly
from "OpenShift Application Runtimes", which is the downstream use
case I'm interested in making easier to maintain), and I think
"Integrated Python" or "Integrated Runtime" accurately conveys the
significance of the proposed stream mapping between Fedora versions
and Python versions ("F28 integration testing uses Python 3.6", "F29
integration testing uses Python 3.7", etc).
For the Testing Runtimes, we could likely just drop the
"interoperability" qualifier, giving:
- Platform Python: the private, always installed, potentially
non-standards-compliant, Python that dnf uses
- Integrated Python: an optional standards-compliant Python used for
development and automated scripting *of* Fedora
- Application Python: used to run Python apps *on* Fedora (but may not
be integrated fully, depending on version)
- Testing Python: sufficient for cross-version compatibility testing,
but not recommended for app deployments
It seems that the Application and Testing Pythons differ only in "SLA"s
and availablility of additional packages, is that right?
Also, it seems that the difference between Integrated Python and
Application Python is that one provides /usr/bin/python3. Is that correct?
--
Petr Viktorin
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
