Pip -t: A simple and transparent alternative to virtualenv in Python

74 点作者 fzumstein将近 10 年前

18 条评论

Galanwe将近 10 年前

I don't really get what this is supposed to solve.- `virtualenv` works by creating an overlay of the `site-packages` in `$VIRTUALENV`, and change the shebang of scripts to use absolute path of python in the overlay. That way, not only do you get dependencies isolation, but you can also call directly your programs from outside the virtualenv and it will work.What you propose is both bad practice (relative path in `$PYTHONPATH`) and rather annoying (you need to be in a specific directory to run everything). Trying to automate that will sure end up in pure hell!- As in "you need to `cd` to _this_ directory then run _that_- Or "WTF it worked on my machine when I was in this directory but now it doesn't"

评论 #9778364 未加载

majke将近 10 年前

I'll use the opportunity to moan about the state of packaging in the Python world. Why, after so many years, there is no way for me to ship software written in python, in deb format?I end up doing some real crazy stuff:* build in docker* using virtualenv /usr/local/mypackage* then manually copy over the init scripts "cp /usr/local/mypackage/bin/* /usr/local/bin"* and debianize "/usr/local/mypackage/" and "/usr/local/bin".Except it doesn't work:* I need root do create the venv in /usr/local.* This technique copies garbage like "activate" script to bin.* virtualenv ships its own python binary. If the python version on host differ, it won't work.* The workaround is to rewrite the bin scripts.Total mess. All I need is a deb with some bin scripts, and all dependencies bundled. Is it _that_ hard...

评论 #9778461 未加载

评论 #9778762 未加载

评论 #9778540 未加载

评论 #9779038 未加载

评论 #9779004 未加载

评论 #9778470 未加载

killerbat00将近 10 年前

> Looking at Javascript, tools like npm and Bower provide the easy, reliable and powerful package management capabilities which it feels like Python is missing. The key to their success? Both tools download a copy of the right versions of the right libraries, by default placing them in a special folder directly within your project's directory.Isn't this exactly what virtualenv does anyway? Plus, with virtualenv you don't have to muck around in your $PYTHONPATH and you can still choose which Python version is installed for each virtualenv.This article doesn't seem to explicitly mention any, but what are the compelling reasons to use pip over pyenv/virtualenv for project isolation? I guess using 1 tool to install dependencies and isolate your working environment is handy. I'm unsure if the overhead of virtualenv is so high that it offers a compelling reason to switch (at least for me).

publicfig将近 10 年前

I'd hardly consider virtualenv with virtualenvwrapper "overkill". It's a pretty elegant and incredibly easy solution to conflicting dependencies that is capable of being used on almost any other environment easily.

评论 #9778757 未加载

gdamjan1将近 10 年前

oh, it's 2015 and people still don't know about pep-370, PYTHONUSERBASE and pip install --user :(<a href="https://www.python.org/dev/peps/pep-0370/" rel="nofollow">https://www.python.org/dev/peps/pep-0370/</a>

评论 #9778621 未加载

评论 #9783212 未加载

deathanatos将近 10 年前

> forget about source env/bin/active and deactivate!If the activate/deactivate bothers you, you can also just call the interpreter directly: env/bin/python ; you can also call any pip-installed binaries similarly. For example, env/bin/ipython if you have that installed. Or env/bin/pip.I have a small utility[1] to magic that to "vpython" and "vipython" and "venv pip", respectively. (The last one is the general "execute this binary in the virtualenv" form; the utility makes some assumptions about how you name your envs, however, but also searches up the tree (I can cd into a dir, so I don't need to do ../../env/bin/python… or source the env.) I believe there's another implementation of this idea out there, but I can't find it at the moment.(My vim is/was a bit python-heavy, and sourcing envs utterly breaks it if I attempt to start vim with an env sourced, since it gets the right vimrc, but the wrong pip installation)[1]: <a href="https://github.com/thanatos/vpython" rel="nofollow">https://github.com/thanatos/vpython</a>

pbhowmic将近 10 年前

I started using pip -t ever since I started coding for AppEngine. I prefer it to a virtualenv becaus it works out a lot neater with the dev server. App engine's earlier approach was to use either virtualenv or pull all the dependencies' code down into the project directory but lately, the App Engine team have started recommending using pip -t instead.

stefanha将近 10 年前

Careful using relative paths in PYTHONPATH.If you share a file system with untrusted users (like /tmp or an NFS mount) or extract an untrusted archive (zip, tar, rar) then you might inadvertently execute python code that another user placed there!It's the same reason why you shouldn't use PATH=. in your shell.This poor man's virtualenv doesn't seem like a good idea...

ptx将近 10 年前

This is a very bad idea, for the same reason that relative directories are not on the regular PATH on Unix: On a multi-user system, or even a single-user system that sometimes has untrusted files on it, you can't safely use your tools if they can be overridden by whatever someone happens to have placed in the current directory.For example, if you're looking through various home directories for some file, you might be doing something like:<pre><code> $ cd /home/foo $ ls $ cd /home/bar $ ls </code></pre> If your PATH contained ".useful_stuff/tools" and the user bar happened to have a file called "/home/bar/.useful_stuff/tools/ls", that file has now been executed instead of /bin/ls, with your privileges. Your account has now been compromised.Try this:<pre><code> [ptx@hn downloads]$ python3 -c 'print("hello")' hello [ptx@hn downloads]$ export PYTHONPATH="./.pip" [ptx@hn downloads]$ python3 -c 'print("hello")' You have been owned! Have a nice day. hello [ptx@hn downloads]$ cat .pip/site.py print("You have been owned! Have a nice day.") </code></pre> For this same reason, if you use Mercurial on a repository owned by someone else, you get something like:<pre><code> [root@host foo]# hg stat not trusting file /home/ptx/foo/.hg/hgrc from untrusted user ptx, group users </code></pre> Microsoft had a related security problem a few years back where they would load DLL files from the current directory: <a href="https://isc.sans.edu/diary/DLL+hijacking+vulnerabilities/9445" rel="nofollow">https://isc.sans.edu/diary/DLL+hijacking+vulnerabilities/944...</a>

AUmrysh将近 10 年前

This is a nice, simple solution to segregating python package environments. I personally prefer virtualenv, as I can navigate around the filesystem and open ipython from anywhere within the venv. I guess I don't see the usefulness of it so much because I have no problem using virtualenv.The relative path is an interesting trick, I'll have to keep that in mind in the future.

erikb将近 10 年前

Since the packaging wars end of 2012 to beginning of 2013 I was following relatively closely packaging and requirements tracking, and let me say this: We don't need another solution. We need the solution we have to work better. Pip+Virtualenv is enough to learn and handle and nowadays works well for most use cases. It's maybe not perfect but it gets the job done. Problems I still see: Most of all integration with the system's package manager; pip3 install -e will be overwritten by the corresponding pypi package if you increase the version, although the -e installed version is already the required one; sudo pip3 freeze doesn't work, at least on the current Ubuntu.There are so many little details that need to be fleshed out in such an infrastructure tool, we can't solve all these boring problems multiple times.

thefreeman将近 10 年前

There is probably an obvious answer to this, but a cursory google search turned up no answers.The idea of having different multiple versions of dependencies on a single system is not exactly a new problem, and is solved by many other package managers. Is there some inherent weakness in python modules that forces them to be managed this way? Do the maintainers of pip insist on this for other reasons?It seems like one of the bigger complaints I hear about python so I feel like it must be harder then it seems.

评论 #9779655 未加载

goblin89将近 10 年前

IMHO complexity created by limited isolation facilities of virtualenv and the likes isn’t worth the resources you save by not just having a VM for each app you work on.The complexity arises from differing system-wide dependencies that are out of scope of various package managers or virtual environments, and from development environment (assuming we’re addressing the need to have multiple apps co-exist on one machine for development) not matching production.

fizixer将近 10 年前

Not sure why it tries to replace virtualenv which is already obsolete in favor of pyvenv which is built-in.

评论 #9779181 未加载

wkornewald将近 10 年前

Also have a look at vex: <a href="https://github.com/sashahart/vex" rel="nofollow">https://github.com/sashahart/vex</a>Unlike this pip solution, vex extends your PATH to include installed scripts. It also works well on Windows and is really easy to use.

personjerry将近 10 年前

Isn't it rather dangerous to have a "transparent" version of virtualenv?

w_t_payne将近 10 年前

This is somewhat similar to what I do ...

评论 #9778107 未加载

fit2rule将近 10 年前

Packaging: if you have to do it, you should be building a bootable, distributable, OS instead.Doesn't matter how many times others learn this lesson, I personally see it over and over.