Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pypi.python.org

Post reply on HN
Print view View original

31–35 of 35 posts

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

#31

Post by sashahart »

isbadawi wrote: post #26

I like this. I've used both virtualenvwrapper and pew before, but they both have lots of features I don't use. Using this plus some small shell functions like the below to create, list and delete virtualenvs is enough for me. function mkvirtualenv { virtualenv "$HOME/.virtualenvs/$1" if [ $# -eq 2 ]; then vex "$1" pip install -r "$2" fi } function lsvirtualenv { ls "$HOME/.virtualenvs" } function rmvirtualenv { rm -r…

It looks like there is a lot of demand for --make/--remove options to vex so I will do those (and that should nearly approach the end of the new features I will do on vex).

Probably good to do some error checking on the arguments to mkvirtualenv and rmvirtualenv (sleepily hitting enter too early, etc.)

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

#32

Post by goblin89 »

sashahart wrote: post #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…

Well, I use the postactivate hook to set environment variables (for convenience) and connect to project-specific tmux session.

    export PROJECT=`cat $VIRTUAL_ENV/.project`
    export SRC=$PROJECT/src

    [ -z $TMUX ] && cdproject && envopen
Where envopen is my own script that launches tmux (basically tmux -f $TMUXCONF -L $ENVNAME attach -t $ENVNAME with a few checks).

This solution has a lot of flaws, though: it isn't robust and doesn't make sense for non-Python-based projects (my work is not limited to Django). In fact, I'm working on switching to dedicated VMs for my projects—looking for a nice solution currently. I suspect it may involve Vagrant, Docker, perhaps Chef.

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

#33

Post by deathanatos »

tudborg wrote: post #9

Looks good. I currently use http://tudb.org/articles/2014/03/31/vpython/ for pretty much all of my python projects (also, i am the author of vpython).

Well huh.

> Vpython is a tiny(-ish) bash script to help with your day to day virtualenv needs.

> * You don't have to worry about sourcing the activate script.

> * You don't have to point to your virtualenv path.

> just use vpython instead of python to invoke your scripts.

That's basically why I wrote vpython: I'm the author of this vpython[1], which isn't the same as yours, nor what the article is. (I suspect mine is a little more immature, as I've not worked on it for as long.) I guess similar needs beget similar utilities.

  [1]: https://github.com/thanatos/vpython

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

#34

Post by e12e »

crdoconnor wrote: post #23

I usually do this just by cd'ing to the project directory, which has the virtualenv inside it and running './venv/bin/python'. That eliminates the possibility that I'll accidentally run the wrong version of python - e.g. a system python or a python from another environment that didn't properly deactivate. Most other issues are easy to deal with (e.g. non-existent virtualenv, being in the wrong folder), but the issue…

I mostly do this, along with a little hack for certain commands I need, such as mercurial: I have a virtualenv under ~/opt/venv/py-2.7-misc, and make a symbolic link from ~/opt/venv/py-2.7-misc/bin to ~/opt/pybin -- and then my .bashrc checks for a ~/pybin and adds it to the PATH if it exists ( [[ -d "${HOME}/pybin" ]] ...).

So I can just go "pip install -u mercurial", or "pip install " without worrying too much. And (my) "hg" is in my PATH -- and I can still run stuff in custom virtualenvs on a project basis, just as you say, by specifying the full path (./proj/venv/bin/python ...).

I've never understand why people use anything more complicated.

I do see occasions where activate is useful -- certain packages, I think scipy and pygame are among them -- are not only rather difficult to install via pip, but also tend to be very picky about their environment. Normally I get by by just installing those (and other packages with strong c/c++ library dependencies) via the package manager though.

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

#35

Post by tudborg »

deathanatos wrote: post #33
tudborg wrote: post #9

Looks good. I currently use http://tudb.org/articles/2014/03/31/vpython/ for pretty much all of my python projects (also, i am the author of vpython).

Well huh. > Vpython is a tiny(-ish) bash script to help with your day to day virtualenv needs. > * You don't have to worry about sourcing the activate script. > * You don't have to point to your virtualenv path. > just use vpython instead of python to invoke your scripts. That's basically why I wrote vpython: I'm the author of this vpython[1], which isn't the same as yours, nor what the article is. (I suspect mine is…

Ha. How fun :)

We take different aproaches though.

Repo link for reference: https://github.com/tbug/vpython

Mine expects you to know virtualenv and how it works, and also that you explicitly install it. Same goes for dependencies.

My needs where to avoid sourcing the virtualenv, so i wrote the tool to fix just that. Also, i built mine to resolve symlinks and be usable as the shebang in your python scripts, which is pretty neat when writing command line tools.

Post reply on HN