Drop older Pythons from versions

[adamv]

Suggest that we drop older Pythons form the versions tap, since they haven't been kept up-to-date with install style changes we've made for 2.7.x and 3.3.x.

Would rather not suggest we support these, even in "versions" (unless someone wants to modernize them.)

[MikeMcQuaid]

Seems reasonable.

[leepa]

Very reasonable as these branches don't receive any security updates people really shouldn't be touching them. Even if they do stay, there should be some kind of huge warning telling people that these versions don't get updates.

[jacknagel]

I'm in favor of this.

[kdopen]

Didn't want to create a new issue, and can't find a discussion list anywhere for homebrew.

Okay, this is done, and I can sort of see the reasoning behind it. But it might have been a little hasty.

My recent 'brew upgrade' took me to python 3.4 with seemingly no problems, until I tried adding py34 as environment to my tox.ini file. At which point I see:

$ tox
-bash: /usr/local/bin/tox: /usr/local/opt/python3/bin/python3.3: bad interpreter: No such file or directory

I am developing a library with full cross-version support from python 2.6..3.3. My virtual environment for development had been running 3.3.5 and the installed tox script calls out the explicit version rather than just using python3. That I can fix by just wiping the virtual environment and recreating it.

The bigger problem is that the brew upgrade unlinked python3.3 from /usr/local/bin. The cellar is still there, but the binary is no longer in the path (which python3.3 == '').

I really needed to install python3.4 alongside python3.3 so that I can continue to run all my unit and functional tests under every supported python version.

How do I get back from this state? Is python3.4 using the same sitepackages directory etc as py33 used to use? i.e did it create a new one for py34 or just overwrite the old one?

Yes, the older versions no longer get security updates, but many machines are still running them and script maintainers need to make sure they are still supported. Travis-ci, for example, doesn't yet offer a test environment for 3.4.

And of course, may linux distros don't necessarily keep updating their ppa's for new versions (think how quickly eclipse gets stale in Ubuntu). Thankfully, Ubuntu actually lists the different versions of python separately so you can apt-get install pythonxy and have side-by-side installations. But there's seemingly no way to do that with homebrew.

I can see this being a continuing problem for python2.8 and 3.5 (when it comes).

[MikeMcQuaid]

@kdopen We don't support linking multiple versions for the same formulae at once. You'll need to manually add both Cellars to your PATH.

[kdopen]

@mikemcquaid Or alternatively do a system install of python3.3 and then relink the brewed 3.4 I guess.

But that kind of defeats the purpose of homebrew. I guess languages are a different beast than, say, a library. But actually I can see developers wanting to keep multiple versions of many things installed ..

• libraries
• compilers
• eclipse (yeah, I know there's no formula for that)

Pretty much anything you need available to debug issues in an old, but still supported, release. So it might be something you want to consider adding (brew upgrade --preserve <formulae>, or something similar)

So, if I add the 3.3 cellar to my path, will it pickup the correct sitepackages?

[kdopen]

Actually, for that matter how does someone revert a brew upgrade? Having recreated the virtualenv with 3.4 I can run all my tests again (needed to disable 3.3 testing for now), but now find some of the style-checking tools aren't 3.4 compatible (flake8 throws and exception under 3.4, but not 3.3).

At this point, reverting to 3.3 would be a feasible option for me. This has to happen with other formulae, where an upgrade just doesn't take so you want to revert and then pin the formula.

This is just a prime example, I suspect. It seems that 3.3->3.4 is not actually a minor patch as defined by SemVer 2.0. My suspicion is that the AST module has changed some return types.

[MikeMcQuaid]

I believe brew uninstall python3 will uninstall the most recent version and you can relink the older one with brew link. I may be wrong though.

Chances are if you're wanting multiple versions of a e.g. library installed you should use a tool dedicated to that job like e.g. pyenv

[kdopen]

Ironically, the first line of the Installation instructions for pyenv states 'If you're on Mac OS X, consider installing with Homebrew.' But they're actually saying to use brew to install pyenv :)

Live and learn I guess. I used homebrew to manage my installs, virtualenv + pip to manage all my python odds and ends, and yes rbenv for ruby. Guess I need to get used to yet-another-version-manager with pyenv.

But the problem with pyenv is that, like rbenv, it 'hides' the other versions so that only one version is visible in the environment. When you run tox, it needs to find all of the python executables to create the virtual environments used to run the tests against each version.