I worked on python for a few months last year, and although I didn't find anything representing a canonical description of that workflow, I did eventually come to this conclusion. The only thing was that pip freeze > requirements.txt didn't really give the same power as I was used to with Gemfile.lock and the various permutations of bundle update. I forget the specifics, but I remember being unable to get the finer points of optimistic version locking to work in a way I found acceptable.

That said, I have been doing ruby since before Bundler, and I really have to take my hat off to what Yehuda and company accomplished with Bundler. It was both a technical and open source community triumph to get Bundler done, stable and covering the breadth of use cases it applies to.

You're going to have a hard time supporting multiple versions of Python that way. If I started a new package today I would target 3.4, 3.5, 3.6, 3.7-dev, and likely, 2.7. A lot of well maintained packages have different dependencies based on the exact version of Python. If you're crazy enough to support 2.6, then there will be a lot of additional packages in pip freeze.

Ideally, packages would have just one set of dependencies and the packages would be version locked, but that's just not the case in the Python community.

Just target 3.4+ then...

Why would you sort 2.6 in 2017?

Supporting 2.7 these days in a new package is already a bit of a wtf - Django for example drops support for it next year.

For the industry I work in, because of this: http://www.vfxplatform.com

We're still maintaining stacks on py 2.6 which predate the reference platform specs

Ok. It looks like they also drop python 2 next year?

They plan to release the spec like that, but I'm certain on this update most studios will be lagging due to the vast amount of 2 to 3 migration work that needs to be done.

Oh well knuckle down and use six for another couple of years then.

At least you're not trying to write Fortran compatible with the 77 and 90 specs....