On Sat, Dec 27, 2014 at 8:50 AM, Michał Górny <[email protected]> wrote: > Hello, > > The current design for getting the 'best implementation' is far from > pretty. It pretty much relies on constant preference order, setting > Python 2.7 over other implementations for practical reasons. As a side > effect, various ebuilds rely on that particular order, e.g.: > > DEPEND="doc? ( dev-python/epydoc[$(python_gen_usedep 'python2*')] )" > REQUIRED_USE="doc? ( $(python_gen_useflags 'python2*') )" > > which pretty much assumes that *if python2 is enabled*, then any > version of it will be the best impl. I find this disgusting, and I'd > like to replace it with something more explicit. >
Yeah, relying python_compile_all running under python2.7 is no good. > > Specifically: > > 1. python_export_best becomes deprecated for good, > > 2. python_setup changes API to: > > python_setup [<impl-wildcard>...] > > alike python_gen_* functions, defaulting to '*'. Now it chooses > the best impl from implementations matching the specified patterns, > e.g.: > > python_setup 'python2*' > > would get the best version of CPython 2. > > 3. we introduce extra variable for distutils-r1 (oh cruel world, how > should we name it?!) that applies wildcards to python_*_all() phases. > This sounds like a reasonable idea, and a natural extension of the python_setup function. > > As for the choice within the list the algo needs to stay as-is for now. > However, in the future we could either: > > a. respect EPYTHON and fallback to the other algo, > > b. respect pre-defined order i.e. 3.4 > 2.7, > > c. respect the order in PYTHON_COMPAT -- however that could be a little > surprising to devs. > > > What are your thoughts? Starting/ending with EPYTHON from the environment seems wrong, and doesn't seem to add value anyway. I would prefer to stick with a predefined order unless someone can present a case where the ebuild author really needs to control it.
