On Thu, Nov 14, 2019 at 3:28 PM Miro HronĨok mhroncok@redhat.com wrote:
On 14. 11. 19 21:15, Stephen Gallagher wrote:
Now, python3:3.7 vs. python3:3.8 might be a more interesting question...
The way Python is designed, 3.7 and 3.8 is parallel installable by default.
The only things that conflict are:
- package names, such as python3 or python3-pytest
- executable names, such as /usr/bin/python3 or /usr/bin/pytest
By having the python3 modules with 3.7 and 3.8 streams, we would kill this feature of Python while gaining a very little benefit (such as that users/admins might select a stream to determine what version /usr/bin/python3 is).
Not to mention that dnf itself depends on Python, so we would need to have dnf in those modules, or rewrite dnf in Rust or use mcirodnf or have /usr/libexec/platform-python for dnf.
I was actually thinking more along the lines of: leave the actual python packages as non-modular but have a module that acts like the old `alternatives` tool to set up which binaries should own the main executable names. It would allow us to do the thing I proposed earlier around the major upgrade rebuilds (letting us set other modules as `buildrequires:` of `python: [ ]` for stream expansion) without actually having to build the complete python stack in the modules. That might be a really convenient strategy, honestly.