Live data from Hacker News

Show HN: Vex, a new way to run things in Python's virtualenvs

pypi.python.org

1–10 of 35 posts

Re: Show HN: Vex, a new way to run things in Python's virtualenvs

#3
This is based on my personal experience with tools for using virtualenv.

virtualenvwrapper is very powerful with all kinds of hooks but I just never used all that power and needed things like speed more. virtualenvwrapper provided a lazy loader but that would have various problems from time to time as you'll see on the issue tracker.

So then for a long time I just ran 'virtualenv' and source wherever/bin/activate and found that I really didn't miss virtualenvwrapper all that much, which was a surprise because everyone finds 'workon' invaluable, a position I do understand.

Later my wife taught herself virtualenv and then wrote like 5 lines of shell to do the same thing as virtualenvwrapper (the classic environment-modifying thing) which I found hilarious, and I wrote a version of that in zsh with a little more error checking to make me happy and just jammed it in my dotfiles. Then after some months of using that I decided this is nice enough to publish so I worked on rewriting it as portable shell functions with more error checking and was going to put it on PyPI.

Toward the end of writing that I was feeling pretty finished, when some last detail that I forget made me hacked off about modifying the current shell environment, so on a lark I wrote a prototype of the new idea of only modifying a spawned process's environment in about an hour (most of which was learning further about portable shell) and once it was working I looked at implementing more error checking for all the weird conditions that may arise in shell and I said, you know what, I have no reason not to do this in Python and totally cut the dependency on which shell is being used, who is going to use this without Python anyway?

Then I ended up figuring out how to do prompts and completion and pretty much had a publishable project, which was surprising.

It's still faster to directly run the virtualenv's Python or to use your own small shell function but while YMMV, for my uses virtualenvwrapper is a lot of code I will never use and I use vex every day.

Highlights of my todos: pydoc still doesn't work (the reasons for this are lame) and probably it will be nice to implement --make/--remove to substitute mkvirtualenv/rmvirtualenv (which would also let me dump a pydoc script in virtualenv's bin/ or Script\ dir to fix that problem...)

Re: Show HN: Vex, a new way to run things in Python's virtualenvs

#4

This is based on my personal experience with tools for using virtualenv. virtualenvwrapper is very powerful with all kinds of hooks but I just never used all that power and needed things like speed more. virtualenvwrapper provided a lazy loader but that would have various problems from time to time as you'll see on the issue tracker. So then for a long time I just ran 'virtualenv' and source wherever/bin/activate and…

> pydoc still doesn't work

Are you using `pydoc` on the command line? If so, try pdoc: https://github.com/BurntSushi/pdoc. I wrote it as a tool to replace epydoc (strictly automatic documentation), but it works on the command line just like pydoc. (It can also generate HTML documentation with cross module linking that isn't crap. See an example here: http://pdoc.burntsushi.net/nfldb)

Re: Show HN: Vex, a new way to run things in Python's virtualenvs

#5
Ha. I always thought something was unnecessarily awkward about virtualenv, but I couldn't quite put my finger on it. Virtualenvwrapper was an improvement in many ways, but its lack of portability could be a pain. Reading the docs, Vex makes perfect sense. We should use virtualenv basically the same way we sudo. It's kind of amazing it took this long for someone to do it. Thanks!

Re: Show HN: Vex, a new way to run things in Python's virtualenvs

#6
I'm very happy more people are coming around to this idea, despite multiple independent discoveries. :)

Here's another project that attempts something similar: https://github.com/berdario/invewrapper

Here's a sortof-blog-post and some more discussion about the superiority of modifying a subshell rather than sourcing a bunch of janky shell-functions that modify your current shell: https://gist.github.com/datagrok/2199506

Re: Show HN: Vex, a new way to run things in Python's virtualenvs

#8

Ha. I always thought something was unnecessarily awkward about virtualenv, but I couldn't quite put my finger on it. Virtualenvwrapper was an improvement in many ways, but its lack of portability could be a pain. Reading the docs, Vex makes perfect sense. We should use virtualenv basically the same way we sudo. It's kind of amazing it took this long for someone to do it. Thanks!

Vex seems very convenient, but it is also possible to avoid the "magic" with just standard virtualenv.

If you provide the full path to the python binary in the virtualenv, it executes with the virtualenv loaded:

  /home/acjohnson/virtualenvs/foo/bin/python myscript.py
This is useful for crontabs, system service config, etc. which don't load a regular user's bash setup files.

Re: Show HN: Vex, a new way to run things in Python's virtualenvs

#10

This is based on my personal experience with tools for using virtualenv. virtualenvwrapper is very powerful with all kinds of hooks but I just never used all that power and needed things like speed more. virtualenvwrapper provided a lazy loader but that would have various problems from time to time as you'll see on the issue tracker. So then for a long time I just ran 'virtualenv' and source wherever/bin/activate and…

> everyone finds 'workon' invaluable, a position I do understand.

At first I wanted to praise virtualfish [1] and its ability to automatically activate a virtualenv when I cd into it, but then I realized that vex's way does indeed make more sense. What do we do in a virtualenv? We basically just run pip to do various things, or run the program (in case it's an application and not a library) or test suite.

So yeah, I think I'm gonna switch. The added portability is a nice bonus.

[1] https://github.com/adambrenecki/virtualfish

Post reply on HN