Live data from Hacker News

Use pew, not virtualenvwrapper, for Python virtualenvs

planspace.org

1–10 of 57 posts

Re: Use pew, not virtualenvwrapper, for Python virtualenvs

#5
post #3

Why not just plain virtualenv?

There's a link in the article which explains why https://gist.github.com/datagrok/2199506

So basically I could start up another shell with that as a launching command and it'd be straight back to being "appropriately unixy"

Re: Use pew, not virtualenvwrapper, for Python virtualenvs

#7
post #3

Why not just plain virtualenv?

There's a link in the article which explains why https://gist.github.com/datagrok/2199506

You can use virtualenv without `bin/activate`. Just refer to `bin/python` (and other scripts in `bin/`) explicitly. Don't bring in the magic until you need it. And when you need it, consider what kind of magic you need. If you're typing `bin/` too much, do you need something that adds `bin/` to your path, or do you need to write a script for this task that saves you from having to type both `bin/` and a bunch of other command-line flags?

(I do add my virtualenv's `bin/` directory to my path, but mainly so my editor can find the right tools, so I do it from elisp instead of bin/activate in a shell)

Re: Use pew, not virtualenvwrapper, for Python virtualenvs

#8
What I really want is to be able to type " foo.py", where creates a list of all necessary dependencies to run foo.py. Then " run foo.py" would automatically do whatever voodoo needs to be done to run foo.py regardless of where you run that command.

The idea is that we all have global pip installations, which is great for hacking. I have a ton of Python scripts that depend on my pip installs. All my scripts run successfully on my box. The goal is to be able to send you one of my scripts along with , then you can run " run foo.py" on your box, and everything "just works."

That way there is literally zero configuration. I don't have to tell any tool anything, and it's effortless for you to run it with all the benefits of a virtualenv.

Re: Use pew, not virtualenvwrapper, for Python virtualenvs

#9
I'll take a chance to plug `vrun` https://pypi.org/project/vrun/ here as well which is a very lightweight wrapper around activate that only applies to the current command. You can use it to start a subshell if you wish.

The fundamental problem is that virtualenv scripts are not actually bound to their actual virtualenv. If you forget to activate and a script shells out in a subprocess to execute another script it will not find the version installed into the virtualenv. This should be fixed upstream but so far it doesn't look like it is.

    $ python3 -m venv env
    $ env/bin/pip install vrun
    $ env/bin/pip install foo # assume foo depends on bar and tries to start bar via subprocess
    $ env/bin/foo # fails because bar is not on the path
    $ env/bin/vrun foo  # works
`foo` is now executed in a process in which the virtualenv is fully activated and will find appropriate dependencies on the path if it tries to run a subprocess, etc.

Re: Use pew, not virtualenvwrapper, for Python virtualenvs

#10
post #7
post #3

Earlier quoted context omitted.

There's a link in the article which explains why https://gist.github.com/datagrok/2199506

You can use virtualenv without `bin/activate`. Just refer to `bin/python` (and other scripts in `bin/`) explicitly. Don't bring in the magic until you need it. And when you need it, consider what kind of magic you need. If you're typing `bin/` too much, do you need something that adds `bin/` to your path, or do you need to write a script for this task that saves you from having to type both `bin/` and a bunch of othe…

How do you manage dependencies? One of the best parts about virtualenv (to me at least) is that I can do pip install without infecting the rest of the system.

I guess I've never looked, does virtualenv provides a bin/pip which already knows the path of the virtualenv? Does the bin/python in there come with a path that uses the project pip install?

Post reply on HN