|From:||"William L. Thomson Jr." <wlt-ml@××××××.com>|
|Subject:||Re: [gentoo-dev] Reverse use of Python/Ruby versions|
|Date:||Thu, 20 Apr 2017 18:24:10|
|In Reply to:||Re: [gentoo-dev] Reverse use of Python/Ruby versions by Christopher Head
On Thu, 20 Apr 2017 10:49:04 -0700 Christopher Head <chead@×××××.ca> wrote:> > >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.Stable according to whom? Gentoo or Python? Take Ansible as an example. Any contributions must work in both 2.7 and 3.x. While I think they require 2.7. Any modifications must also be good for 3.x. Its forward looking. https://docs.ansible.com/ansible/dev_guide/developing_python3.html> >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.It is how other projects, some rather large like Ansible are addressing the issue.>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.Interesting you mention Ubuntu LTS, as that is specifically mentioned on the Ansible python FAQ.> 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.That is a result of the language of choice. Why I do not bother doing anything myself with Python. I am forced to with Ansible till an alternative in another language comes about.> >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.That addresses 2 of the issues right there. You do not care what version of Python you have. Most any systems administrator does care about what version of things are installed. Not to mention what is installed. Like hardended binary systems, tend to not have gcc, etc. I am doing some python dev for Ansible. But also having to package some python stuff, and do not like it from either user, developer, nor packager perspectives.>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.If you were targeting embedded and working with others like ulibc, etc then you may care. But that is interesting for anyone to be coding not caring about versions etc. I do Java dev mostly and some C. I do very much care about versions of stuff when coding. In C I have to write ifdef, etc for such. In java slotting and making sure using the right version. Only Go language seems to not care about versions, just pulling live from major versioned branches. Most everything else is versioned for a reason.> >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.That you are on -dev mailing list. Not sure that would put you in the normal use category. Though there are normal users who run ~arch. They would experience such issues. It is different on stable, as I do not believe there is as many. -- William L. Thomson Jr.