On 29 August 2017 at 19:33, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/25/2017 10:23 AM, Nick Coghlan wrote:
>> 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.
My aim is to be able to define a "Fedora 28 + Python 3.7" container
image that meets the following criteria:
1. Everything that's installed by default is owned by an RPM (no
injecting extra symlinks as part of the container build process)
2. Invocations of "python3" and "/usr/bin/python3" (whether
interactively or via shebang) run Python 3.7
3. I'm able to do this with just the Fedora Modularity tooling - no
extra downstream tools like scl-utils
>> 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?
If that's all they depend on, I guess they'll still be installable.
However, if they depend on a particular version of the Python ABI,
then the 3.7 package won't provide it.
>>> 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?
Originally that's what I had, but as I wrote it up in more detail (see
https://github.com/fedora-python/fedora-python/commit/e76aa19870627059c9b1539f19060e77ef95317e)
I came to realise that it probably makes more sense to have a module
level dependency from the Integrated Python branches to the
corresponding Application Python branches and then have the "python3
symlink or not?" distinction exist between the Application module
config and the Testing module configs.
That way, the "Integrated Python" module shouldn't actually need to
pull in any new source trees - it just becomes a way of mapping from
Fedora versions to their integrated Python versions in a
machine-readable way such that other Fedora modules can easily declare
either "build for all Fedora Integrated Python streams" (by defining a
module dependency on "python: []") *or* "build for all CPython version
streams" (by depending on "cpython: []").
While exactly how the stream expansions are going to work is still a
bit fuzzy (and I assume that's one of the things that will be resolved
at Flock this week), my understanding based on the last fedora-devel
thread about it is that we'll want to actively discourage folks from
doing the latter without a compelling reason, as that's the approach
that can lead to a combinatorial explosion of component builds: every
version of Python on every active version of Fedora. While there are
some cases where we'll actually want to do that (e.g. for the
python-ecosystem modules), there are a lot of Fedora components that
only need to be usable on the Python build that's integrated directly
with the OS.
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
