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.
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
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).
> 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
>>>> * Default Python Module
>>> 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.
Ugh, you're right - I completely overlooked that problem when I
dreamed up that particular hack. That means providing a nicer error
message than the default "interpreter not found" one would depend on
either:
- being able to "anti-register" a file in RPM and/or DNF (i.e. saying
"I know I put a file there, but it's not a real implementation, so
please don't actually use it to satisfy any dependencies")
- providing some other way to customise the "interpreter not found"
message that doesn't involve installing a stub interpreter
implementation
While the first of those actually sounds vaguely plausible, I'm not
sure I dislike the current error message enough to put in *that* much
effort into trying to improve it.
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
