From: Francesco Riosa <vivo75@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions
Date: Mon, 10 Apr 2017 00:48:58 +0200 [thread overview]
Message-ID: <f4c9b5b2-1c58-ddcd-7bc8-8201bcab95d2@gmail.com> (raw)
In-Reply-To: <20170409152002.550f3b4d.dolsen@gentoo.org>
On 10/04/2017 00:20, Brian Dolbec wrote:
> On Sun, 9 Apr 2017 23:36:18 +0200
> Francesco Riosa <vivo75@gmail.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.
next prev parent reply other threads:[~2017-04-09 22:49 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-09 16:15 [gentoo-dev] Reverse use of Python/Ruby versions William L. Thomson Jr.
2017-04-09 21:36 ` Francesco Riosa
2017-04-09 22:20 ` Brian Dolbec
2017-04-09 22:48 ` Francesco Riosa [this message]
2017-04-09 23:15 ` William L. Thomson Jr.
2017-04-09 23:59 ` Michael Orlitzky
2017-04-10 0:37 ` Francesco Riosa
2017-04-10 0:58 ` William L. Thomson Jr.
2017-04-10 14:57 ` Michael Orlitzky
2017-04-10 15:49 ` William L. Thomson Jr.
2017-04-09 21:44 ` Kristian Fiskerstrand
2017-04-09 22:28 ` Francesco Riosa
2017-04-09 23:08 ` William L. Thomson Jr.
2017-04-09 21:52 ` Michael Orlitzky
2017-04-09 22:34 ` William L. Thomson Jr.
2017-04-09 22:42 ` Francesco Riosa
2017-04-09 23:04 ` James Le Cuirot
2017-04-10 5:33 ` Hans de Graaff
2017-04-10 1:38 ` Kent Fredric
2017-04-10 2:04 ` William L. Thomson Jr.
2017-04-10 4:35 ` Kent Fredric
2017-04-10 15:52 ` William L. Thomson Jr.
2017-04-10 21:30 ` Kent Fredric
2017-04-10 17:58 ` Christopher Head
2017-04-10 18:12 ` William L. Thomson Jr.
2017-04-10 20:11 ` Vadim A. Misbakh-Soloviov
2017-04-20 17:49 ` Christopher Head
2017-04-20 18:23 ` William L. Thomson Jr.
2017-04-21 12:53 ` Kent Fredric
2017-04-10 19:40 ` Alan McKinnon
2017-04-10 6:37 ` Michał Górny
2017-04-10 13:21 ` Dirkjan Ochtman
2017-04-10 17:50 ` Michał Górny
2017-04-10 16:03 ` William L. Thomson Jr.
2017-04-10 17:14 ` Michał Górny
2017-04-10 17:49 ` William L. Thomson Jr.
2017-04-10 18:10 ` Michał Górny
2017-04-10 18:44 ` William L. Thomson Jr.
2017-04-10 18:57 ` Mart Raudsepp
2017-04-10 19:38 ` William L. Thomson Jr.
2017-04-10 19:51 ` Mart Raudsepp
2017-04-10 20:01 ` William L. Thomson Jr.
2017-04-10 20:17 ` William L. Thomson Jr.
2017-04-10 20:32 ` Mart Raudsepp
2017-04-10 20:21 ` Mart Raudsepp
2017-04-10 20:33 ` William L. Thomson Jr.
2017-04-10 20:43 ` Michał Górny
2017-04-10 21:33 ` William L. Thomson Jr.
2017-04-10 21:44 ` Mart Raudsepp
2017-04-10 22:51 ` William L. Thomson Jr.
2017-04-10 21:56 ` Michał Górny
2017-04-10 22:42 ` William L. Thomson Jr.
2017-04-10 22:09 ` Kent Fredric
2017-04-10 22:35 ` William L. Thomson Jr.
2017-04-10 22:56 ` Kent Fredric
2017-04-10 23:04 ` William L. Thomson Jr.
2017-04-10 19:31 ` Vadim A. Misbakh-Soloviov
2017-04-10 19:38 ` Ciaran McCreesh
2017-04-10 19:57 ` William L. Thomson Jr.
2017-04-10 20:29 ` Vadim A. Misbakh-Soloviov
2017-04-10 20:40 ` William L. Thomson Jr.
2017-04-10 20:48 ` Vadim A. Misbakh-Soloviov
2017-04-10 21:27 ` William L. Thomson Jr.
2017-04-10 20:51 ` Michał Górny
2017-04-10 21:18 ` William L. Thomson Jr.
2017-04-10 21:33 ` Michał Górny
2017-04-10 21:58 ` William L. Thomson Jr.
2017-04-11 4:48 ` [gentoo-dev] " Duncan
2017-04-11 17:47 ` James Potts
2017-04-11 21:02 ` Michał Górny
2017-04-10 21:17 ` [gentoo-dev] " Vadim A. Misbakh-Soloviov
2017-04-10 21:25 ` William L. Thomson Jr.
2017-04-10 22:22 ` Kent Fredric
2017-04-10 19:49 ` [gentoo-dev] No Java Team, Java neglect was -> " William L. Thomson Jr.
2017-04-10 20:04 ` Rich Freeman
2017-04-10 20:15 ` William L. Thomson Jr.
2017-04-10 20:58 ` Rich Freeman
2017-04-10 21:21 ` William L. Thomson Jr.
2017-04-10 21:31 ` Rich Freeman
2017-04-10 21:54 ` William L. Thomson Jr.
2017-04-11 9:18 ` Kristian Fiskerstrand
2017-04-11 15:22 ` [gentoo-dev] OT Getting to know others in Gentoo was -> " William L. Thomson Jr.
2017-04-11 15:57 ` Kristian Fiskerstrand
2017-04-11 22:23 ` [gentoo-dev] " Viktar Patotski
2017-04-12 7:25 ` Kristian Fiskerstrand
2017-04-10 21:48 ` [gentoo-dev] " Kent Fredric
2017-04-10 20:26 ` William L. Thomson Jr.
2017-04-25 9:16 ` Sergey Popov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4c9b5b2-1c58-ddcd-7bc8-8201bcab95d2@gmail.com \
--to=vivo75@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox