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

[Christopher Head]

On April 10, 2017 11:12:10 AM PDT, "William L. Thomson Jr." <wlt-ml@××××××.com> wrote:
>Are you running stable? There are other versions in tree. 3.4, 3.5,
>3.6. If you were running unstable, you would have 4 pythons, including
>2.7. That you only have 2 seems like you are running stable.

Yep. Absolutely. I bring in ~ versions of packages when I have no choice.

>If your writing new python code against say 3.4 and not 3.6. Not sure
>about that... Seems like it would keep things bound to older versions
>and never let things move forward.

Not true. I will certainly move forward when a newer version becomes stable.

>Usually when writing new code, you use the latest version of stuff. Not
>always but usually best. If anything make code support older while
>targeting newer.

No, not how I develop. I always start by determining my target audience and then develop using a feature set that allows my target audience to use the code as easily as is practical. I wouldn’t use a syscall introduced in kernel 4.9 if I could avoid it, even if it made my code simpler, because most of my colleagues run Ubuntu LTS, they are part of my target audience, and it wouldn’t be available there. To me, responsible development practices mean NOT forcing my target audience to do a manual kernel build. Eventually the syscall will be “generally available” to my target audience, at which point I may go back and change the code.

I wouldn’t build conditional branches that do it either way if I could possibly avoid it, either, because then I would have to do all the work of doing it the old way plus more, and it would also be more code which means more maintenance.

>> Eventually 3.5 will get
>> installed and 3.4 will go away. Just like every other package. I
>> won’t need to do any config file editing, just a revdep-rebuild run
>> perhaps. So regardless of the situation for maintainers, as a user, I
>> don’t see this pain.
>
>Because you are not setting or dealing with the targets. You went with
>the mindless approach. Like doing a wildcard on USE flags.

Yes, exactly. I don’t want to manually choose what version of Python I have installed, even though I sometimes do Python development. Just like I do a lot of C/C++ development, but I don’t want to manually choose which version of glibc I have installed. Or libfoo, for some foo. That’s what a depgraph is for, and if I do need some specific thing, then I will ask for it, but not before.

>Your enabling support for all versions across the board for anything
>that supports it. That is quite a different experience if you go trying
>to use a specific one.

I’m not trying to invalidate the pain that some people experience, just pointing out that I think it may be inaccurate to call that the “ordinary user” use case.

-- 
Christopher Head