4 ms·

A virtualenv is just a bunch of packages, you end up with the same thing whatever you want to call it. It is probably a more roundabout solution that it needs t

• cutler 6y ago
  He also said virtual envs install their own copy of Python. No need for that either. Coming from other languages the whole virtual env thing seems alien especially the way it messes with your shell.
  • iandinwoodie 6y ago
    A virtualenv (venv) does not install its own copy of Python. Instead, when you create the venv it puts symlinks for the calling python in the <venv>/bin directory. When you activate the venv the <venv>/bin is added to the front of your PATH so that any "python" commands use the symlink'ed version of Python corresponding to your venv.
    • aequitas 6y ago
      Indeed, a virtual env is really not that exciting or complicated. Even "activating" a virtualenv is just changing your shell's PATH so it picks the virtualenv binaries, nothing else. You can also just call those binaries directly from their installed location in the env without ever having to "activate" or "workon" anything.
  • danmur 6y ago
    Activating the venv is completely optional. I never do it, but some people seem to like it.
    • user5994461 6y ago
      It's not optional. It's required for things to work properly. A basic example of something that would break if the environment is not activated is binaries, like mypy. You have a script that calls "mypy"? Gotta be in the virtual environment to invoke it, otherwise the executable might not be found, or worse, it might run another executable.
      • danmur 6y ago
        It's absolutely not required, I assure you. If you run the Python binary inside the venv you have the same environment as if you'd activated the venv, but only for that execution and not affecting your shell. Try making a venv, running python, and looking at sys.path.
        • user5994461 6y ago
          I assure you 100%, it is required for everything to work, it's not just here for the show. One of the thing that the virtual environment does is modify the PATH to lookup executables from the virtual environment first. This is to ensure that when a script calls binaries like mypy/python, it's going to find the same binary from the environment it's currently running in. Typically if the environment is not activated, python is going to lookup to /usr/bin/python and might be something else. This is most noticeable when there are different versions of python on the systems and when having scripts that invoke themselves.
          • danmur 6y ago
            I see we will not agree, and this thread is mostly dead anyway, but for posterity: it sounds like you haven't installed mypy into the venv you're using. I can see how that would not work. I don't try and reference python scripts that I haven't installed using the venv so perhaps that's why I've never encountered this situation. If it's part of my project it's installed into the venv (and if it's a dev dependency like mypy, which I do use, it gets installed as a dev dependency so it doesn't end up in releases).
  • globular-toast 6y ago
    Do you not use nvm or something similar then? That "messes with your shell" in exactly the same way.
• pfranz 6y ago
  I haven't used Poetry and most of my workplaces have done their own thing with versioning Python packages. So my virtualenv experience has been on my own or with toy projects. I really like writing one-off or sporadically used commandline tools. Loading a virtualenv or navigating to a directory before executing kind of sucks. Generally, I install into my homedir. I haven't read through or tried this out, but it seems like it might better address this use case. You're right, this seems to be very similar. To me, it looks like it removes one abstraction layer of pushing-popping the environment.
  • renewiltord 6y ago
    I have recently found Golang to be a good alternative. I too like Python and still write lots of scripts in it merely out of familiarity.
  • teraku 6y ago
    You can execute the python binary inside the venv's bin/ folder directly. But you still need the full path I guess
    • pfranz 6y ago
      You could add that bin/ to your PATH, but you'd also need something else to load the venv before executing it. You could write a generic wrapper that would load the env and call the Python binary and put that in a more generic bin/, but that's the kind of thing this proposal seems to make irrelevant. Another issue with wrappers is how quickly it executes. It's not a big deal for most executions, but for --help or building up a command pipeline it's really annoying to wait a second or two on each execution. That slow startup time also shows up when you start integrating it into automated processes.