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

21–30 of 35 posts

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

#21

Post by sashahart »

Deejahll wrote: post #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/2199…

I did not know about invewrapper, thanks. pew is another decent name.

edit: after looking at the doc, my impression is that invewrapper seems to follow virtualenvwrapper's design more closely with a large number of subcommands with names similar to virtualenvwrapper's, most of virtualenvwrapper's options and features (except hooks and maybe some of the project stuff). I would describe the options as "comprehensive." I specifically wanted something with a dramatically simpler interface and feature set.

invewrapper also seems primarily or only intended to run a shell. I get personal use out of running arbitrary commands under vex as if it were sudo or something.

It is an improvement not to modify the current environment and couple tightly to specific shells either way, though.

One thing I do envy is the PowerShell prompt ;)

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

#22

Post by tudborg »

sashahart wrote: post #17
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).

Ah, discovering it from the directory. I considered this in analogy with the way vagrant works.

Downside is, ofc, that compared to just running something inside a virtualenv shell, vpython takes forever (up to 100ms-ish on my machine) to find the virtualenv, and set the correct env variables.

Most of my projects are long running though (webservers, number crunchers, etc), so the extra miliseconds it takes to load is really not that important.

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

#23

Post by crdoconnor »

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 of accidentally using the wrong environment is awful because it can manifest itself with subtle bugs or weird exceptions rather than an obvious error.

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

#25

Post by berdario »

sashahart wrote: post #21
Deejahll wrote: post #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/2199…

I did not know about invewrapper, thanks. pew is another decent name. edit: after looking at the doc, my impression is that invewrapper seems to follow virtualenvwrapper's design more closely with a large number of subcommands with names similar to virtualenvwrapper's, most of virtualenvwrapper's options and features (except hooks and maybe some of the project stuff). I would describe the options as "comprehensive."…

(invewrapper/pew author here)

I just discovered your project, so I haven't tried it yet, but since the approach seems similar, it should work just fine on Windows (maybe with some tweaks)... and you can just add the Powershell prompt to your docs, no need to envy it :)

I agree that pew is intended as a virtualenvwrapper replacement, obviously you can get something similar to `vex env cmd` with `pew in env cmd`...

Unfortunately I've neglected a little bit the project lately: the most serious thing I want to do is rewrite the test suite, to be able to run it on windows.

Since you mention PowerShell maybe you use it quite often? I'd like to get some feedback on Windows (I added Windows support out of completeness, but I seldom use that OS), since I don't know anyone who uses pew on windows :)

BTW, I discovered some new tools to manage environments in the last year:

pyenv (I actually already knew rbenv), modules[1] and I even started to use Nix

These have not the same scope, and in fact I appreciate the latter 2 idea of using the same system to manage dependencies and versions for all different kind of tools. I don't have an opinion yet on what's the correct way to do these things so, in the meanwhile, even tools that are python-specific (like ours) have a niche to fill

[1] https://archive.fosdem.org/2014/schedule/event/hpc_devroom_e...

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

#26

Post by isbadawi »

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 -rf "$HOME/.virtualenvs/$1"
  }

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

#27

Post by burntsushi »

sashahart wrote: post #18
burntsushi wrote: post #4

Earlier quoted context omitted.

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

I do sometimes, more as a matter of muscle memory than volition. I'm going to make a try to use your tool as a replacement for a while and see if I can generate any issues for you :) However, I still would like to eventually unbreak pydoc for users who might have bad habits like I do. The issue is that virtualenv itself had an opportunity to fix this (with multiple patches submitted IIRC) and they decided to punt by…

> I guess maybe not that many people use pydoc anyway?

That would be my guess. IMO, pydoc isn't very discriminating with what it produces. The HTML is pretty ugly and the command line version just kind of vomits everything in the module to stdout. My idea with pdoc was to try and discover a module's public interface, and then display that.

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

#28

Post by StavrosK »

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

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

Am I the only one who activates the virtualenv by hand? I don't understand what workon and other things provide. These days, I just have a single virtualenv that gets sourced when my shell starts up, all my projects run in virtual machines (I mostly work with Django). Projects that conflict with others get their own virtualenv, but sourcing it once at the start of the day is still not that much hassle.

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

#29

Post by StavrosK »

schwuk wrote: post #12

I've never bothered with virtualenvwrapper - I create virtualenvs alongside my projects, and call `$virtualenv/bin/python` or `$virtualenv/bin/pip` etc. directly. Sometimes I activate the virtualenv, sometimes I don't.

That's what I do too. I mostly activate them by hand nowadays, just to avoid calling python. Fish is smart enough that it knows that, if I type a period in a directory that contains a virtualenv, I want to activate it.

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

#30

Post by sashahart »

StavrosK wrote: post #28
runiq wrote: post #10

Earlier quoted context omitted.

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

Am I the only one who activates the virtualenv by hand? I don't understand what workon and other things provide. These days, I just have a single virtualenv that gets sourced when my shell starts up, all my projects run in virtual machines (I mostly work with Django). Projects that conflict with others get their own virtualenv, but sourcing it once at the start of the day is still not that much hassle.

You aren't, I do it all the time. But it does get slightly tedious to type out the whole path. (when switching virtualenvs frequently, unlike your use case)

What I use that is analogous to your single virtualenv sourced at shell startup, is pip install --user. I tend to use that for command line tools like style checkers.

Post reply on HN