[lug] Running a mixed Python environment

[Davide Del Vento]

On Tue, Sep 15, 2020 at 7:58 AM Rob Nagler <nagler at bivio.biz> wrote:

> On Tue, Sep 15, 2020 at 2:17 AM Steve Litt wrote loads of flamebait:
> > Some projects are huge, but the Python folks announced in 2008 that
> > they'd sunset in 2015, and eventually moved that out to 2020.
>
> Can you explain why Dropbox, a company founded in 2007, who hired Guido
> van Rossum in 2012, still was migrating the code base in 2020? (Dropbox may
> still be using py2. There hasn't been a "we're done" blog post afaict.)
>
> Flame: I have heard that the Python folks have learned their lesson, but
> they are still breaking APIs on every minor release and sometimes on patch
> releases. Every time we upgrade Python versions or use PIP, it's a
> crapshoot of whether we lose hours or days fixing things.
>
> Read Steve Yegge's post on why backward compatibility is important:
>
> https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc
>

I agree with what he said about Google, but I think asking the same to the
open source community is a different thing. In a sense Python (like many
other pieces of software) is somebody's baby that they wrote to scratch an
itch. It may fit our needs and so we use it, but unless you are paying
someone (like Dropbox was doing), you are at the mercy of the developer(s).
It's painful, but why should they do what you and I, the unpaying
customers, are asking? Our needs are a lot of work, in the present, not to
mention the past and the future. Things need to have been done well, with a
forward looking attitude in the beginning -- which often is missing. Now
what? Plus, it's not fun (the reason why they joined the project in the
first place), quite the contrary: it's very tedious. So, as an "end user" I
totally agree with you, that is what I want. But I've lived on the other
side (even paid), and I can tell you, it's not pretty and I think for most
project is not going to happen. The example you provide of the opposite I
think are (and will remain) the rare exceptions.


> Or read my post on why semantic versioning (aka romantic versioning) is a
> joke and also why backwards compatibility is important:
> https://www.robnagler.com/2015/04/11/Major-Release-Syndrome.html
>

Interesting post. I like chronological versioning, but that assumes there
will never be the need for a "fork" for bugfixes. Even Ubuntu, IIRC, adds a
"minor" number to their versioning (after year and month), especially the
LTS.
I would love to live in a world in which what you say actually happens.
Unfortunately the plethora of hardware and software we use (even paid one)
is so complicated.... I have no idea on how to make happen in practice what
you say for a large project, let alone for different projects with
competing needs! Case example: two applications utilizing the same
underlying communication library -- one application wanting bit-for-bit
reproducibility first, the other wanting highest performance first. How to
update the library with these two competing needs? Major-minor numbers
allow that, chronological versioning doesn't. As you know this is NCAR's
bread'n butter

Cheers,
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20200915/02e0fd1c/attachment.html>