On 9 February 2015 at 00:29, Ben de Groot <[email protected]> wrote: > On 8 February 2015 at 04:38, Michał Górny <[email protected]> wrote: >> Hi, >> >> Just a quick idea: >> >> 1. we set default PYTHON_SINGLE_TARGET to 3.* matching PYTHON_TARGETS, >> >> 2. python2.7-only ebuilds get implicit 2.7 via axs' patch, >> >> 3. py2.7+pypy ebuilds -- we enable 2.7 via package.use. >> >> >> Goals: >> >> a. have as high coverage as possible of ebuilds that can be installed >> with default USE set. >> >> b. Make it cleaner to install py3-only ebuilds. Right now, user gets to >> enable 3.* manually, and then maintain the entry whenever 3.* is >> upgraded to newer version. >> >> c. Improve 2.7+3.* ebuilds by replacing 2.7 with the faster & better >> 3.* :). >> >> d. Make it easier to switch 3.* version. When user wants to change it >> from 3.3 to 3.4 or the other way around, he just needs to adjust PST >> and 2.7+pypy ebuilds still work fine. >> >> Your thoughts? > > I recently switched one of my installs from python 2.7 to 3.4, because > I thought it was finally time to "get with the times". But in my > (admittedly limited) experience goal A would still be covered by 2.7. > > It would be good to have a more comprehensive inventory of how many > (and which) packages work with 2.7, and which don't, and compare that > with the numbers for 3.4. > > At the moment I would say: I wish we _could_ default to 3.4, but I > think 2.7 is still the more sensible default.
As a follow-up, I did a qgrep in the tree for python support the other day, and it turns out we have: - almost 2500 ebuilds with 2.7 support only - less than 1500 ebuilds with support for both 2.7 and 3.* - only just over 100 ebuilds that support 3.* only Based on these numbers, it is clear to me that the most reasonable default is: PYTHON_TARGETS="python2_7" PYTHON_SINGLE_TARGET="python2_7" and leave it to the user to change that if they really want multiple python versions. This would also significantly reduce the size of our stage3 tarballs. -- Cheers, Ben | yngwin Gentoo developer
