On 14. 11. 19 22:01, Stephen Gallagher wrote:
On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 14. 11. 19 21:32, Stephen Gallagher wrote:
On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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.
Convenient to achieve what exactly?
To achieve an easy way to deal with modular rebuilds for new Python 3 versions.
Easy is subjective. I don't consider this easy. I consider it seriously
overcomplicated. The idea that going modular will somehow help with current
problems in modularity is exactly what happened to eclipse.
I'm not going to do this. I guess that after the RHEL 8 experience, neither are
the remaining Python maintainers.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
