[onatrain]

> there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change

The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact).

(Seems like a lot of people are using system Python, which isn't really recommended.)

[fsh]

I started a project in 2016 and used pipenv to freeze all the dependencies. A few weeks ago, I could not get it working on a new machine. Apparently the new system python broke some of the libraries. I had also pinned the python version in pipenv, but it seems like pipenv can only install python versions that are not too old.

I really like the language, but all the tooling is seriously broken.

[viraptor]

If you upgrade the runtime / compiler, you'll run into changes of behaviour. This really applies to almost every implementation out there. This applies across the board with large enough codebase.

[pksebben]

pyenv will make your life easier in this regard. that is all.

[fsh]

Pipenv has pyenv integration. It just doesn't work with python 3.6 on my machine. My guess is that it tries running pipenv itself with the old interpreter and is no longer compatible. In any case, faffing around with 25 different third-party solutions is a horrible developer experience.

[pksebben]

I feel you.

Fwiw what I've settled on that seems the most stable is to use pyenv as the "outer layer", as it shims the python interpreter along with any venvs so you don't get conflicts / heisen-incompatibility. Lets you use anaconda envs as children as well. The real trick, I think, is to pick one system as the canonical master env controller and don't deviate.

[cinquemb]

Yeah, I have no problem running stuff from a decade ago because of virtual env and pip freeze (even across diff oses).

[jacquesm]

I have no problem running stuff from a decade ago either on the same box and installation that it was on a decade ago. But virtual environments and pip freeze are closer to mothballing an old box than displaying long term code compatibility and functionality. Their main reason to exist is as a workaround precisely because there are such issues.

The whole idea that you need a multitude of environments to support applications written in the same interpreted language is where it breaks, that should not have been necessary if backwards compatibility had not been an issue.