Hi folks,
[Note: this may not make much sense to folks that haven't been closely
following the Modular Server work for F27. If that's you, sorry -
hopefully this will be more comprehensible by the time I officially
propose it for F28, as the relevant terminology becomes more widely
understood. In the meantime, check out
https://docs.pagure.org/modularity/ to learn more]
I'm working on a draft proposal for a "Default Python" module (see
https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
for details), and hit an interesting challenge when it comes to
defining the containing images that we want to be able to build from
our module definitions.
A quick summary of what I'm expecting we'll have by F28:
- a separate platform-python binary in the Platform module
- python2 modules with a full 2.7 stream and a partial
interpreter-only 2.6 stream
- python3 modules with a full 3.6 stream and a TBD set of other streams
- a default-python module to switch between no-default,
python2-default and python3-default
With those modules defined, a minimal Fedora container image will only
include platform-python, but we'd at least also have Python3-F28, and
Python2-F28 images that included the respective user Python stack in
addition to the platform Python runtime.
The part I'm struggling with is this: Python 3.7.0 is expected to be
released in June 2018, while Fedora 28 is due out in May 2018. It
would be *really nice* to be able to define a Fedora 28 based Python
3.7 container where "/usr/bin/python" and "/usr/bin/python3" were
both
references to "/usr/bin/python3.7".
The challenge with actually doing that lies in the "/usr/bin/python3"
symlink: integrated userspace Python applications in F28 are going to
expect that to still refer to the Python 3.6 stream.
One way I could potentially see this working:
* the normal non-conflicting setup is as follows:
* the python3 3.6 stream includes a "/usr/bin/python3" symlink
* the other python3 3.x streams do *not* include such a symlink &
hence don't conflict
* the default-python python3-default stream does *not* include such
a symlink & hence doesn't conflict
We then add some more streams to the default-python module that *do*
include a "/usr/bin/python3" symlink: python3.5-default,
python3.7-default, etc
The trick with these streams is that they would *conflict* with the
regular python3 3.6 stream, due to the disagreement over what
"/usr/bin/python" means. That dependency resolution conflict would
then mean that have a non-default version of Python 3.x configured as
the default when defining your container would *prevent* you from
including any regular userspace Python components - you'd only be able
to include the ones built specifically for that stream.
Does that approach sound sufficiently plausible to folks that I can
use it to provide feedback to the folks working on the modularity
tooling as to the capabilities we think we'll need?
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia