Really? Pip should be pretty straight forward. Maybe you use different libraries than I do.
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.
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.
This is kinda discouraging :)
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 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.
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.
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"
Packaging/distribution is certainly a mess.
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...
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.
Pretty simple, no? Most any python project I have seen in the last 5-6 years uses it.
We are using `pip-tools` to manage that: https://github.com/jazzband/pip-tools
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.
if you are using windows, using python without this website is nearly impossible: http://www.lfd.uci.edu/~gohlke/pythonlibs/
"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.
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.