On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 14. 11. 19 21:32, Stephen Gallagher wrote:
> On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok <mhroncok(a)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.
Convenient to achieve what exactly?
To achieve an easy way to deal with modular rebuilds for new Python 3 versions.