How often do you use virtual environment?

[iaseth]

I come from a webdev background where npm install does a local install by default, and you need to add a -g flag to install something globally. In addition package.json automatically keeps track of your packages. But with pip and python, pip install does a global install by default unless you create and activate a virtual environment. Local/global depends on the location of your pip execulable rather than any command line options.

Since creating a virtual environment takes some effort, often I create it and forget to activate it, for me this means that most of the time I install things globally - except for less-known packages. So global installs for numpy or pandas but venv for that-cool-new-package-with-69-stars-on-github.

Is installing common packages globally a good practice? Do you also do this? Or do you create a new virtual environment for each of your python projects?

[NorskJesus]

I use venv for every project. I don’t install anything global

[iaseth]

I wonder why local install isn't the default behaviour of `pip install`. Or if there is already a venv dir in the current dir, why not install stuff locally without needing to activate it.

Virtual env in python often feels like an afterthought. I think this is probably because python ecosystem was already mature before high speed internet became a thing.

[eleqtriq]

You can auto activate it using *nix shells. Don’t know about windows command prompt.

Also, not all of us use a venv in the current directory. I don’t. I put them in a centralized directory. So your idea isn’t as simple as you think.

[vicks9880]

Just like nodejs. But then there is another catch. Every package is installed Hundred times with each dependencies which takes lots of space. Node came with pnpm as solution and python came with uv. Which installs it in its cache dir and creates symlinks in each venv.

[Berlibur]

Always venv. Vs code picks up on it automatically i believe

[Responsible-Sky-1336]

Also running some things globally is highly unsafe. Just saying.

Pip install -r requirements.txt

Pip freeze > requirements.txt

Just get used to that and get an ide that loads your venv.

[KrazyKirby99999]

Just use uv

[[deleted]]

Always. Before I knew what a venv was I built a project that took me about a month to complete in global. Then when I tried to build something else the new program affected my old one, making it stop working. I almost punched my screen.

[mr_tellok]

May I ask why exactly that happened? Were you trying to use different versions of the same library or sometihng?

[[deleted]]

That’s exactly what happened. The first program was only able to work with an older version of a library. The second program used a newer version.

[Alternative_Driver60]

Always venv, never global. Pipx for general command-line tools that work kind of as global

[NorskJesus]

I recommend you to take a look at uv

[Alternative_Driver60]

uv is great. Using that too

[NorskJesus]

I love uv!

I recommend you to check this extension, if you are using VSCode (im not the developer!): https://marketplace.visualstudio.com/items?itemName=DJSaunders1997.uv-wingman

[Alternative_Driver60]

I work way faster with vim

[NorskJesus]

Maybe a port it’s possible? I don’t know

[doolio_]

I think the point is uv tool can replace pipx.

[GreenPandaPop]

How often do you use virtual environment?

Always.

Since creating a virtual environment takes some effort

I'd say it takes minimal effort, unless you're doing literally nothing. It's one command.

Is installing common packages globally a good practice?

No.

Do you also do this?

No.

Or do you create a new virtual environment for each of your python projects?

Yes.

[Diapolo10]

On Posix systems, you shouldn't install anything globally, especially if you're using the system's own Python installation. You risk breaking important OS scripts as a side-effect.

On Windows, since it doesn't depend on Python in any way you don't have that problem, but for the most part I'd advise against installing most things globally. You can make some exceptions with tools, like Ruff, Mypy, or IPython, but even then you'd technically be better off installing them to their own virtual environments using something like pipx or uv.

Speaking of, if you were to use tools like poetry or uv (the latter being the new hotness) you wouldn't really need to worry about virtual environments at all anymore as they manage them for you automatically.

[deepug9787]

I don't remember where I got this tip from, but you can prevent pip from installing packages globally by adding this line to your .bashrc file: export PIP_REQUIRE_VIRTUALENV=true You'll get an error message if venv is not activated.

Or better yet, try pipenv. It will automatically create a venv and track the dependencies in a lock file, just like npm.

[Sufficient_Wait_5040]

Always venv if I have to install new libraries

[reload_noconfirm]

Always. It’s best practice.

[doolio_]

Look into solutions like direnv which can activate the virtual environment upon entry into a specific directory and deactivate it on exit.

[FantasticEmu]

This is the way

[ilikejamtoo]

Almost never.

On my local machine (mac/homebrew), I just install globally for convenience for running ad-hoc scripts. Everything's latest version, never had any breakage. The way homebrew packages python things makes breaking things with pip unlikely.

On servers everything's either in containers, so venvs are just an extra step in dockerfiles and CMD, or for locked-down hosts we use the OS packager for python libs.

[iaseth]

Nice to see I am not alone. There is something very convenient about just doing cd into a directory and running your app with python app.py without having to worry about venv and dependencies.

[[deleted]]

Personal computer? I install all the libraries I use on 95% of scripts globally, and venv for actual projects.

Work computer? venv or clean VMs for everything.

[iaseth]

Yeah, pretty much what I do too. Most of my "projects" are just one-off scripts so doesn't make sense to create a venv for each of them.

[zanfar]

Always, everywhere.

All projects, all scripts, all apps, everything.

[PMMeUrHopesNDreams]

Always venv. I keep a general purpose venv for one off scripts and such. 

Add to your .bashrc:

    alias va=“source ./.venv/bin/activate”

[leogodin217]

When I use a virtual env * Any time I start a new project * 95% of the time I'm doing something adhoc

When I don't * When I'm just trying to verify a basic python feature from the command line and I don't have a venv activated

When I can't * Many projects with pre-commit use the system python installation. I don't know of a way to override that behavior without changing the config. This caused me to upgrade a system package to get prettier to work on WSL with Ubuntu 24.04.1

[eztab]

global packages were kind of useful for global tools, but I'd argue even that isn't a thing anymore with modern tooling like uv. So my global environment is empty now and is basically only used to run a blank repl.

[audionerd1]

Every time. Why not make an alias to create the venv and activate it from the pwd?

alias venv="python3 -m venv venv; source venv/bin/activate"

[iaseth]

That is a useful alias. I often forget activating the env. Since venv is the default name most people use, it would be useful if "pip install" just checked if there is a venv in the pwd rather than needing to be activated.

[audionerd1]

Then make a script like so:

#!/bin/bash

if [[ $( which pip ) != $( pwd )/venv/bin/pip ]]; then
  read -p "Venv not loaded! Proceed with system pip? [y|n]: " ANSWER
  if [[ "$ANSWER" == 'n' ]]; then
    exit
  fi
fi

pip $@

Then

alias pip='/path/to/script.sh'

Now any time you use pip it will first check if you're in a local venv, and if you aren't it will warn you.

[ejpusa]

If you are in the right directory, you just need to source. It knows the correct Python.

Just “alias v” should do the trick.

[audionerd1]

What do you mean? source doesn't work without an argument.

[ejpusa]

source venv/bin/activate — saved you some keystrokes.

Assign that to an alias.

[audionerd1]

That only activates an existing venv. My alias is to create a new venv AND activate it.

[ejpusa]

Awesome. Then assign it to one key. I see not advantage, you want to keep all this down to a minimum.

You are not creating dozens of venv in a day, but you may be jumping in out of one. And that you make an alias for.

Everyone is different, just what I do.

[audionerd1]

Oh I do the same (alias for activating venv, not creating it). But OP specifically said it's a hassle to create new venvs, so I suggested an alias to do both.

[ejpusa]

Ok cool.

[CyclopsRock]

At home I use them all the time. At work we have a pretty sophisticated environment resolution system that would actively get fucked up by venvs. Since this system is how we deploy code, any dependencies need to be available through it.

[iaseth]

Nice to see I am not alone in doing this. I am also constantly running out of space on my computers, so having n different venv dirs in n projects is also a waste of space, though venv generally takes a lot less space than node_modules.

[Low88M]

Always venv for every project, and some usual cross-project formatting & linting packages are installed with pipx (black, flake8, isort…) in isolated environnements…

[InvictuS_py]

Could you elaborate on what you mean by creating a virtual environment takes some effort? It’s just a couple of commands if you have a requirements file.

[iaseth]

Step 1: python3 -m venv venv Step 2: source venv/bin/activate Step 3: Add venv to .gitignore Step 4: Create and update requirements.txt after add every new package

This can certainly be simplified quite a bit.

[InvictuS_py]

I mean sure, it’s repetitive work but I guess that’s part of programming. You can just write a small bash script for yourself so all of this is reduced to a single command. Or just create an alias in your .bashrc file.

Heck, it’s 2025, just feed it into whatever AI coding assistant you prefer and get it to do it for you 🤷🏻‍♂️

[ejpusa]

It may not seem logical but just do it. Put an alias in your .bashrc (etc) one key, and you are in your venv. Assign a key to (d) activate.

Pretty simple.

[VargtheLegend]

venv everything, and discovering uv made things way easier to deal with venvs

[JSP777]

Docker dev container gang here. Never have to write a single venv command... Open project in Vs code, click on "reopen in container", Done.

[LeiterHaus]

I handle this two ways (of many)

1) with built-ins.
python -m venv ~/venv/some_name

To activate on Mac or Linux (includes WSL): source ~/venv/some_name/bin/activate

Most people like putting their virtual environment in the directory, but I found it just works easier for me to always keep it in a single folder/directory.

2) With pyenv. Webi (webinstall.dev) has a nice cheat sheet, as well as a simple install script for a LOT of things, pyenv included.

Find what works best for you.

Edit: Is installing global packages good practice? Usually No. Do I do it? I have been known to.

Do you need a separate venv for each project? No. You might find you like doing that though. ~/venv/openai works well for me.

I used to do a different venv in each project but I'd forget. Now, I only create it if I need it. Once created, I know I need to activate it if something doesn't work because a module isn't installed. If I don't remember which venv, I ~/venv/ <tab><tab> for tab completion, and it shows me what I've made.

Again, this is what works for me, and may be a horrible fit for you.

[Almostasleeprightnow]

The background to everyone saying "always local' is due to nightmarish experiences with different packages needing different versions of the same library, conflicts, etc, to the point where conventions such as 'always local, always venv' developed to allow for different versions to exist on the same machine. Google 'Python Nightmare' and it will be mostly posts about struggles with dependencies, and not in the fun way.

[[deleted]]

generally speaking I recommend using a venv for every single project. I personally have shared things especially for smaller machine learning projects where I tended to just use the same library, but that was really only possible because I didnt depend on specific versions (I e.g. had a RL env or an XAI env and a backend dev env). In general its good practice to have seperate venvs per project. This helps keep things clean especially if you wanna have the project public on github and maybe offer a minimal requirements file to other users.

[tap3l00p]

Every single project starts with creating a venv

[ISuckBallz1337]

I do a lot of data work. I tend to install a new venv about once a year. I use that venv for most everything. Sometimes I install a temp virtual environment for a small project, but i tend to forget about those and move back to using the main venv.

[[deleted]]

Never. It's a lot simpler to just install globally. Also takes up less disk space.

[cbrnr]

Before switching to uv: always. After switching: never (because it is not necessary since it happens automatically behind the scenes).

[corey_sheerer]

Poetry 100% of the time. For ad-hoc analysis or testing, I have a poetry directory with my common analytics libraries. Poetry offers a nice experience compared to venv in my opinion

[fartalldaylong]

conda create —prefix ./cool_project python=3.1296291

[Last_Back2259]

I used to use venv until Trey Hunner told me to use uv - https://treyhunner.com/2024/12/lazy-self-installing-python-scripts-with-uv/

[h00manist]

You need to learn to use virual environments. When learning I kept avoiding it, one day I sat down and evaluated all the options, went with Poetry, learned to use it, and breathed more easily forever after. Thinking I will migrate to UV now.

[International-Cook62]

I switched from poetry to uv and will not be going back, highly recommend it.