This looks interesting, but personally I don't have any problems with virtualenvs. I use pipx to install "global" tools and virtualenvwrapper to make project envs. It all works fine really.
You don't really need a virtualenv
21–30 of 148 posts
Re: You don't really need a virtualenv
#22Earlier quoted context omitted.
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 to be, but I don't find many problems myself (also using poetry).
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.
Do you not use nvm or something similar then? That "messes with your shell" in exactly the same way.
Re: You don't really need a virtualenv
#23In fact this guy propose to have python be able to work like npm...
Looks like a ridiculous idea to me as node and npm dependencies/node_modules is completely messy and inefficient.
Re: You don't really need a virtualenv
#24As a Ruby and Python developer I often wonder why Ruby doesn't need a virtual env. What did Ruby get right that Python didn't?
Not sure about ruby, but most of the languages I know about, C#, javascript, php, etc don't need virtualenv because they install packages in a project locally (and globally if required). so envs of one project do not clash with another.
while python install packages globally and only globally. so a virtualenv is needed to isolate different projects from one another
Re: You don't really need a virtualenv
#25Earlier quoted context omitted.
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 to be, but I don't find many problems myself (also using poetry).
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…
You can execute the python binary inside the venv's bin/ folder directly. But you still need the full path I guess
Re: You don't really need a virtualenv
#26I recommend virtualenv and virtualenvwrapper. I usually set up a new venv like this: $ mkvirtualenv -a $(pwd) new_venv $ pip install -r requirements.txt When you want to activate this env and cd to the directory where you created it, you can simply do: $ workon new_venv That's all you need to know. It just works.
Honestly just use poetry.
Re: You don't really need a virtualenv
#27> things get tricky when it comes to nested venvs
Never had such a requirement.
Environments, like the interpreter itself, seem a singleton concept.
I have used a Makefile that sources different Bash environment variables kept in files in etc/ within the venv to switch between, say, a Flask and a Gunicorn startup.
Re: You don't really need a virtualenv
#28Interesting idea, and props for implementing something on top of an existing PEP.
Re: You don't really need a virtualenv
#29I recommend virtualenv and virtualenvwrapper. I usually set up a new venv like this: $ mkvirtualenv -a $(pwd) new_venv $ pip install -r requirements.txt When you want to activate this env and cd to the directory where you created it, you can simply do: $ workon new_venv That's all you need to know. It just works.
Honestly just use poetry.
This comment would be vastly more valuable (to me at least) if you said why. The parent’s workflow mirrors my own and doesn’t feel onerous.
Being completely unfamiliar, their site says:
> Poetry either uses your configured virtualenvs or creates its own to always be isolated from your system.
So it is just a pretty wrapper? I’m missing the value add.
Re: You don't really need a virtualenv
#30Thanks for writing this. I've always felt that virtualenv was bit of a placebo. I still use it from time to time though because others expect it. In fact I have used it this week on MacOS, and was annoyed to find that I can't install ipdb to my user packages and still see it in a virtualenv. Seems it's either global or local. (I think the --system-site-packages defaulting to off has it backwards, but it is probably reassuring if you don't know how the module finder works).
Regarding nested virtualenvs, last time I checked there was no such thing. When nested, they always linked back to the system level python, and the cloned python had loads of dependencies on the global system. I'm not aware of a valid use case for nesting virtualenvs.
There is one handy feature of virtualenv that I'm not sure __packages__ solves though: console_scripts and entry_points. setuptools will automatically create a console script under /usr/local/bin or similar which hooks in your module under site-packages. virtualenv includes a ./bin directory and adds it to your path so that these console scripts still work locally. Any thoughts on this?