On 08/18/2017 01:38 PM, Nick Coghlan wrote:
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?
That sounds like it would work. But yes, please talk to the Modularity
WG to see if modules can be made to work that way.
--
Petr Viktorin
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
