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

[Kent Fredric]

On Sun, 9 Apr 2017 22:04:13 -0400
"William L. Thomson Jr." <wlt-ml@××××××.com> wrote:

> This has never been the case with Java.

Its not a problem with C binaries either, because you have a discrete
compile time, and language level interop between compiled binary forms.

Meanwhile, you cannot build two parts of a given python dependency chain with
different pythons, nor different perls.

> If package A requires version X, but B Y, then B builds with Y as its
> pulled in as a dep. while A proceeds to build with X.
>
> Where this is different for Python, Ruby, and also Perl. They all
> install files into a directory based on version. You may have multiple
> copies in each, vs one. Perl does not have targets, nor does Java.

Right, but this is impossible with Ruby, Python, and Perl.

Perl *could* have targets, and some people think could do with it, but it
and java are very much in different boats.

Perl is in the same boat as Python and Ruby where in "new version of thing"
means "everything must be compiled with the new target"

Perl simply has a *moving* target instead of multiple concurrent targets.

Essentially, with Perl we've done the effect of "Add X, Remove Y" for all things.

We additionally have a much better precedent than python at syntax-interop between
versions, so its more justifiable to only have the single target ( because you practically
never need an older perl "just for compat reasons", though at the rate this garbage[1] is
going, that could change one day )


If anything, Perl is only avoiding the Python problem you hate with significant amounts
of heroism, and its only a matter of time before upstream force our hands in ways that
make that heroism non-viable, and we have to dig deep and work out how the hell
to maintain concurrent targets.


> The present system is a PITA for users. Fiddling with adding/removing
> targets for Python/Ruby. In addition to selecting which for the system.
> All these same problems exist for Java, with the exception of
> installation locations as mentioned.

I honestly think you're looking at the wrong problem domain to fix this problem,
in ways that will introduce yet more regressions and broken trees.

We should have what I've been saying we should have for a while now:

* Soft Options.

We only have 2 types of option at present from the users perspective, "on" 
options, and "off" options.

Portage doesn't even distinguish between who is setting them, user profile
and the gentoo profiles simply flatten into a single logical profile,
and then portage then demands that changes be made to this set, failing to discriminate
at all between "ok, this was the profile specified default and it needs to be non-default for this problem"
and "user doesn't actually want this, how can we avoid that"

And portage then compounds this by dictating that any option changes that ebuilds need
must be enshrined by the user as things the /user/ wants, when in truth, they're not things
the user wants, they're things the ebuilds want, and the user begrudingly accepts.

Hence why an option of "on, but only if portage really needs it" is missing, but needed.

I would gladly set soft-targets of every python version under the sun, and then allow
portage to turn them on *as necessary*, and this would be much preferable to having to either

a) turn them on globally and pull in stuff and waste time compiling stuff that's not even getting used.

b) Maintain a painful and carefully catered list of things to prevent aforementioned problems.

In short, users need a way to discriminate "things I care about" from "things I don't care about"

Currently, its just a big cluster of those things in one place, and the complexity is inescapably
thrust into the users hands on a daily basis.


1: https://bugs.gentoo.org/showdependencytree.cgi?id=613764&hide_resolved=0