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

[Michał Górny]

Dnia 9 kwietnia 2017 18:15:56 CEST, "William L. Thomson Jr." <wlt-ml@××××××.com> napisał(a):
>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?

It is always nice when a person who:

a. did not bother to do any research on the topic (such as reading previous posts or even asking the relevant teams),

b. has barely any clue (if any at all) about Python ecosystem or package maintenance in Gentoo, 

c. is either completely ignorant of how Python packages worked in the past (which quite proves the points made above) or presumes that they were changed for no reason by incompetent developers,

decides that the workflow of Python team needs to be changed and goes to discuss it on the mailing list with other people who barely do any Python work.

>
>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.


-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)