From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 99B7E139694 for ; Sun, 9 Apr 2017 22:49:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC09F21C07B; Sun, 9 Apr 2017 22:49:01 +0000 (UTC) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 67501E0BF6 for ; Sun, 9 Apr 2017 22:49:01 +0000 (UTC) Received: by mail-wr0-x244.google.com with SMTP id u18so18967531wrc.1 for ; Sun, 09 Apr 2017 15:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=gXFoAJhWgA300IuvJ/3LS8gSQm6fV0ziRgEax8BXonA=; b=fn34LIDgSpmJFItnhtgJpvOSsPKefTy6T5Eo6KeiFdcakfGvXqjYHG1/2i43Pr4I2t p+YNjOSkxF0FhevwSTofggieraurkg1c3hw2YMXxNL2tpIRTD65SErIEt0ujXph9vSF2 zi6rGbphgkFS0BSvXb5oUlOiJP/VegKK7zJ+jI58OSlHfW5eIfsYfg84vzsdB4gjY6vk wLIsbX4idAru5Wh6m2IqPUWenjlcqPguh8HSgvjhsFPc+HTviytT1wnNG/4nyKALKM7w kP1OclyMs74vNW4q+QxfZb0kUxAH+ngQNQT155fencUcqse6mhvGwGBdEKVw44U0tTZm Isbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gXFoAJhWgA300IuvJ/3LS8gSQm6fV0ziRgEax8BXonA=; b=Cj+AK8mqc/zD+BScC8aJjaXBufDxY4crWWjCa6tFUiXJrQBezYlBZ32ydOaIRXqbKP 8iJTlvvcE/l9jBNEGBt5uF1kp48YC8j6o5AG9OK1QakYhEnwsSh0P1pJK1ubitN4fP9/ uoQW1cyWwRunJFh+dhfcYkRayDdJK1xMbNpN/libMLp1P7yPXiPaOntmHk/BQ2jDVcGf TO8KHieEWSjQR8PSBLriW+Q9cn4qnkta8FKnJCW7lnGY2xZI0deyMceULFuB1MFPwgKf Q5JtpI2/Iu8d7Ols2yPoNgIZOZ9k4yMcebSrXgwcjWOuxaXzSam7tQTp/6yM7Lts1+Yf e63g== X-Gm-Message-State: AN3rC/5DRKoPk9BgIMYpYxQG+bNxD79xobSdNPvHr64CKImcHoKFYi0UQP5TkSf/gbJYvg== X-Received: by 10.223.166.146 with SMTP id t18mr2757957wrc.15.1491778139747; Sun, 09 Apr 2017 15:48:59 -0700 (PDT) Received: from [192.168.1.128] (net-5-89-218-40.cust.vodafonedsl.it. [5.89.218.40]) by smtp.gmail.com with ESMTPSA id k63sm7845794wmf.9.2017.04.09.15.48.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 15:48:59 -0700 (PDT) Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions To: gentoo-dev@lists.gentoo.org References: <20170409152002.550f3b4d.dolsen@gentoo.org> From: Francesco Riosa Message-ID: Date: Mon, 10 Apr 2017 00:48:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20170409152002.550f3b4d.dolsen@gentoo.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: c2dfc691-d927-430f-a328-8fbfa1632ea1 X-Archives-Hash: 4ff3af9dfb741410170d6070300d5946 On 10/04/2017 00:20, Brian Dolbec wrote: > On Sun, 9 Apr 2017 23:36:18 +0200 > Francesco Riosa 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.