Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Francesco Riosa]

On 10/04/2017 00:20, Brian Dolbec wrote:
> On Sun, 9 Apr 2017 23:36:18 +0200
> Francesco Riosa <vivo75@×××××.com> wrote:
>
>> On 09/04/2017 18:15, William L. Thomson Jr. wrote:
>>> Not sure if this is practical, it may be less work if the use of
>>> Python and Ruby versions ( maybe others ) is reversed. Rather than
>>> adding all the versions that the ebuild supports. What if it only
>>> included versions it did not support?
>>>
>>> Rational
>>> When new versions are added. Ebuilds must be updated to support the
>>> new version. This can require editing a decent amount of ebuilds.
>>> Many may work fine with the new version. Making this extra needless
>>> work. From a user point of view, You cannot move to the newer
>>> version without keeping older around till all are updated to the
>>> newer version.
>>>
>>> Now one could say its the same work to mark versions not supported.
>>> But I think there is less of that. Also if something supports and
>>> older version and not newer, it may stand out more failing.
>>> Requiring someone to reduce to the older version, and maybe filing
>>> bugs to get it updated to the newer version.
>>>
>>> Python 2.7 stuff aside. I am not sure how many Python and Ruby
>>> packages break with a newer release. In pythons case I think once
>>> they support Python 3.x, there is little chance if it breaking with
>>> further 3.x releases. Not sure about Ruby.
>>>
>>> I could be very wrong and the present way of doing things being the
>>> only way. However if this is feasible it may lead to less work. It
>>> would allow all packages to move to a newer version. Also allowing
>>> punting of older sooner. This leaves the versions solely up to the
>>> eclasses. Then ebuilds simply mark the unsupported versions. Just
>>> like we do now with adding versions it does support.
>>>
>>> Which if something was say only Python 2.7. It would have a >= to
>>> excluded any newer version of Python. That said, we could do the
>>> same with the current way. Saying this supports Python/Ruby >=SLOT.
>>>
>>> Either way I do not think the current way is the best way. You have
>>> to add every version/slot to ebuilds that work fine with any
>>> version. When new ones are added, the ebuild has to be touched
>>> again. When it may work fine with a new version without requiring
>>> the ebuild to be modified.
>>>
>>> This came up with some stuff requiring ruby23 as I moved to 24.
>>> Looking around some stuff has Python 3.5 some 3.6, but all 3.4. So
>>> I will stick to 3.4 till everything is at 3.6. Otherwise no point
>>> and still have other versions.
>>>
>>> The approach mentioned above, if the packages do not have issue. I
>>> could go ahead and switch to ruby24 and pyton 3.6 across the board.
>>> Which I cannot do now till a bunch of ebulids have their targets
>>> increased.
>>>
>> +1 to the python part, cannot speak about ruby.
>> or totally automate the addition of python versions to ebuilds at the
>> exact time of bumping dev-lang/python.
>>
>>
>
> This could be partially automated using buildbot.  The easiest would be
> for pkgs containing working test suites.  Those that pass could be
> auto-enabled with that python with ~arch keywords.  I think if a stable
> pkg is to be added the new python, it should be via a revision bump and
> ~arch'ing the keywords.  But we could enforce the bot to rev-bump all
> ebuilds just as easily.
>
> Pkgs without tests, those would be harder and
> we could do some basic tests on those, like syntax, test imports, but
> would require additional means of testing in order to qualify for an
> auto-python addition.
>
> It should also be possible for the bot to scrape setup.py for
> comppatible python versions.  Many of the pkgs I have been working with
> recently have them listed.  Also there is travis.yml files in many
> upstream pkg repos which can also be scraped for tested pythons.
>
> It could certainly reduce the manpower needed to keep things up to date.
>
All good ideas, if William proposal is rejected, I'd like to request a 
mandatory step like this when a new minor 3.x python version is added to 
the tree.
No idea if that's feasible for ruby too.