4 ms·

I'm curious, what sort of overhead are you seeing with virtualenv that leads you to use this/any alternative? I've used virtualenv + virtualenvwrapper on some

I'm curious, what sort of overhead are you seeing with virtualenv that leads you to use this/any alternative? I've used virtualenv + virtualenvwrapper on some seriously underpowered and low-on-space machines, and have really not noticed enough overhead to even make a blip.

AUmrysh 11y ago
I'm pretty certain virtualenv just changes some environment variables. I found a writeup [1] on how to write your own virtualenv. It doesn't look like there's much overhead there. I suppose one could justify not using virtualenv if they're on a system with limited resources or network access. I've known people who spent hours building a compiling python 2.7 from source on embedded systems because they rolled their own distro, and in that situation it would make sense to not want to mess with virtualenv if you just spent hours getting pip working. 1: https://www.recurse.com/blog/14-there-is-no-magic-virtualenv-edition https://www.recurse.com/blog/14-there-is-no-magic-virtualenv...
- mikemikemike 11y ago
  My impression is that the benefit of this approach is that it fits the mental model of NPM and Bower. Being able to manage packages across your stack using the same kinds of steps feels... organized. The relative path issue, however, needs some more consideration.
ehremo 11y ago
Yeah I think for me it's more about the intellectual overhead than performance. With this you just have one tool, and it's just easier for me to understand what's going on compared with virtualenv.
- Galanwe 11y ago
  Virtualenv is really not complicated. I think your time would be better spent learning how it works than just hacking some crappy workarounds to skip the problem.
  - mbreese 11y ago
    It can be a pain when trying to distribute software to users (non-python programmers). What I usually end up having to do is distribute virtualenv with my code, and include a simple Makefile/build script to setup the venv. Invariably someone tries to then move that directory and everything ends up getting screwed up until I can tell them to run "make clean all". I'm not too sure that this would end up being any easier, but maybe...
    - deckiedan 11y ago
      What I'm doing with streetsign[1] is including a download virtualenv step in the setup script[2]. The virtualenv gets set up in `.virtualenv/`, so most users won't even see it. [1] http://streetsign.org.uk/ http://streetsign.org.uk/ [2] https://bitbucket.org/dfairhead/streetsign-server/src/5b359a4b423c56e1cab2923ac307223a534a80e2/setup.sh?at=master https://bitbucket.org/dfairhead/streetsign-server/src/5b359a...
    - bpicolo 11y ago
      http://nuitka.net/ http://nuitka.net/
      - mbreese 11y ago
        Does that work with Cython compiled dependencies?
    - perlgeek 11y ago
      You can build debian packages that way; dh-virtualenv (https://github.com/spotify/dh-virtualenv https://github.com/spotify/dh-virtualenv) makes it quite easy to pack a full virtualenv into a .deb.

AUmrysh 11y ago

I'm pretty certain virtualenv just changes some environment variables. I found a writeup [1] on how to write your own virtualenv. It doesn't look like there's much overhead there. I suppose one could justify not using virtualenv if they're on a system with limited resources or network access. I've known people who spent hours building a compiling python 2.7 from source on embedded systems because they rolled their own distro, and in that situation it would make sense to not want to mess with virtualenv if you just spent hours getting pip working. 1: https://www.recurse.com/blog/14-there-is-no-magic-virtualenv-edition https://www.recurse.com/blog/14-there-is-no-magic-virtualenv...

mikemikemike 11y ago
My impression is that the benefit of this approach is that it fits the mental model of NPM and Bower. Being able to manage packages across your stack using the same kinds of steps feels... organized. The relative path issue, however, needs some more consideration.

ehremo 11y ago

Yeah I think for me it's more about the intellectual overhead than performance. With this you just have one tool, and it's just easier for me to understand what's going on compared with virtualenv.

Galanwe 11y ago
Virtualenv is really not complicated. I think your time would be better spent learning how it works than just hacking some crappy workarounds to skip the problem.
- mbreese 11y ago
  It can be a pain when trying to distribute software to users (non-python programmers). What I usually end up having to do is distribute virtualenv with my code, and include a simple Makefile/build script to setup the venv. Invariably someone tries to then move that directory and everything ends up getting screwed up until I can tell them to run "make clean all". I'm not too sure that this would end up being any easier, but maybe...
  - deckiedan 11y ago
    What I'm doing with streetsign[1] is including a download virtualenv step in the setup script[2]. The virtualenv gets set up in `.virtualenv/`, so most users won't even see it. [1] http://streetsign.org.uk/ http://streetsign.org.uk/ [2] https://bitbucket.org/dfairhead/streetsign-server/src/5b359a4b423c56e1cab2923ac307223a534a80e2/setup.sh?at=master https://bitbucket.org/dfairhead/streetsign-server/src/5b359a...
  - bpicolo 11y ago
    http://nuitka.net/ http://nuitka.net/
    - mbreese 11y ago
      Does that work with Cython compiled dependencies?
  - perlgeek 11y ago
    You can build debian packages that way; dh-virtualenv (https://github.com/spotify/dh-virtualenv https://github.com/spotify/dh-virtualenv) makes it quite easy to pack a full virtualenv into a .deb.