If you get into the habit of making a virtual environment and requirements.txt in every repo then it's smooth. Just activate the env when you're using the repo and use vanilla pip install to install dependencies. Then pip freeze them into the requirements file. It's a very similar workflow to a gemfile and bundler.

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....

Really? Pip should be pretty straight forward. Maybe you use different libraries than I do.

But be sure to use Pip into this year's flavor of virtual environments rather than globally, since you might have multiple projects that need different versions of the same package. And be sure to run the right version, I've seen situations where a computer had python 2 and 3 installed, somehow python3 became the default when running "python" but if you ran "pip" you'd get dumped into the old version.

And if your editor has a "Run script" function, it also needs to deal with "Activate the correct environment" for whichever flavor of virtual environment you've used.

Any what beginner would be confused by tutorials using all sorts of different setups (virtualenv, venv, pyenv, pipenv, virtualenvwrapper, pyenv-virtualenvwrapper)? Most of them, I think.

"venv" is the newest one - shipped in the python3 package except when it's not (Ubuntu, maybe others) and doesn't make copies of the python binaries for each environment. That always seemed wasteful to me, but I suppose it was the easy way around path problems with the ecosystem not having a solution built in.

I love python when I'm only using the standard libraries, but if I have dependencies it's messier to set up than I want it to be.

Honestly, virtualenv works. Every single time. I use virtualenvwrapper because I find it and the aliases it provides useful.

I'll stop using virutalenv when it actually becomes a hindrance. I know venv exists, but I have precisely zero incentive to use it when virtualenv works and allows me to get on with what I actually want to do.

virtualenvwrapper, virtualenv, venv...

This is kinda discouraging :)

virtualenv is python2, venv is python3. virtualenvwrapper is as described, a wrapper around them to provide some convenience functions, but they're perfectly functional without it.

Those all seem like pretty basic developer best practices to me.

Of course each project needs it's own virtualenv. In fact, each project should have it's own docker image. Why install an application library to the entire system? That is not a good idea in ANY language.

And of course scripts need to use the right virtualenv. Or better yet - why not put each app in it's own docker? That bundles up everything into a single "file" you can run on command.

All of these things you are listing as downsides seem like things that one normally moves away from, when they put a codebase in git and stop deploying to prod by copying a few files to a shared network drive and restarting the server?????

> Those all seem like pretty basic developer best practices to me.

Those are all bleeding edge developer best practices that didn't exist five years ago. Folks coming from matlab (an example I read above,) probably aren't in the industry and many likely don't even know docker exists OR why they would want to use it.

requirements.txt is NOT bleeding edge.

And the GP was saying that the ruby package manager is more magical then the python package manager... when pip solved all of the complaints mentioned.

Odd.

I do mostly Ruby professionally and dabble in Python, and I agree with heydonovan. Pip works fine for installing things, but near as I can tell, Python has no equivalent of bundler - a tool to install specific versions of a bunch of libraries, generate a lockfile ensuring that your production server and all of the devs are all running it with the same version of everything, and letting you have as many versions of a gem installed as you want, and still running a project with specific versions other than the latest.

You can do this, but it's not as easy. The pipfile project is an effort to improve this.

The current standard way to do this is with a virtualenv and a requirements.txt file in which you specify the version of your dependencies, which you can then install with pip install -r requirements.txt.

Format is "packagename==0.1.0" (>=, < etc work too). VCS urls work too btw, e.g. "git+protocol://site/repo@tag_or_commit"

To get something similar (but inferior) to lockfiles you can use "pip freeze > filename"

Look at Pipenv: http://docs.pipenv.org/en/latest/

Packaging/distribution is certainly a mess.

That's not true. A requirements file is the canonical way to do this. Just use a requirements file and pip install -r requirements.txt. Then version control that file and other Devs do the same. Just like a gemfile.

> Python has no equivalent of bundler - a tool to install specific versions of a bunch of libraries

Zope and plone, the project(s) that came up with python eggs, used to have the concept of "known good sets"[1], which were massaged and used with zc.buildout :

http://www.buildout.org/en/latest/

I'm not sure I'd recommend it for greenfield projects - splitting things up in sane-sized chunks, and using the now in-standard-lib vevn (python3 -m venv) is probably a better idea.

But just for the record, there exists a canonical(ish) solution to some of these issues in python-land.

[1] http://grok.zope.org/doc/community/life_cycle/known_good_set...

Sorry to nitpick, but Zope and Plone were not the originators of Python eggs, although they may have popularized them.

The design was done by Phillip Eby, with funding from OSAF for the development of Chandler, not Zope.

Much shade has been thrown at eggs over the years, and people bemoan the warts, but eggs and setuptools were better than what we had at the time in Python.

https://pypi.python.org/pypi/setuptools/0.6c11

pip install -r requirements.txt

Pretty simple, no? Most any python project I have seen in the last 5-6 years uses it.

requirements.txt don't track transitive dependencies. Your project could break if a dependency decided to swap out its own dependencies. This isn't theoretical either - it happened to us in production.

We are using `pip-tools` to manage that: https://github.com/jazzband/pip-tools

What do you mean? `pip freeze > requirements.txt.lock` will freeze all your current deps, including transitive.

This is only practical if you only have one set of requirements.

If you have multiple sets of requirements (for dev vs testing vs production, eg), this becomes impractical real quick. You'll essentially have to tear down and rebuild your dependencies multiple times to update your reqs.

pip (py2) on windows is an absolute disaster. pip install numpy ....

if you are using windows, using python without this website is nearly impossible: http://www.lfd.uci.edu/~gohlke/pythonlibs/

Things are a lot better with Python 3 on Windows, and especially so with Python 3.5+.

"pip install numpy" will actually work, among other things. But even for packages that don't have binary wheels and have to compile things, it's much easier now to install a compiler toolchain (it's actually a single download!), and have your Python installation just pick it up automatically.

> Things are a lot better with Python 3 on Windows, and especially so with Python 3.5+.

For one of my main applications py3 proved to be too slow. For my application I use: numpy, pil, tkinter, and subprocess (and process/produce/draw on screen images (at a rate of 120/sec)). I don't know WHY but with python2 it runs acceptably fast, on python3 it's 20% slower. This has been something common for me actually.

I do tend to use py3 when doing any kind of data science though.