r/learnpython • u/Artistic-Army4423 • 7d ago
Virtual Environment and Python
I have started learning python and decided to use pycharm as an editor. I want to know anything which will help me in this journey.
My main question is => I don't get "virtual environment" thing with python. I cloned a repo and opened it in pycharm, it says "No python interpreter configured for <repo-name>" and then suggested to create virtual environment.
I want to hear things from experience devs.
thank you.
13
u/xaomaw 7d ago edited 7d ago
Let's say you have 2 projects: project A and project B.
Project A needs library X in v1.2 and project B needs library X in v2.5.
So if you only have a common library, you would always have to install v2.5 when using project B and if you want to switch to project A you would also have to re-install v1.2 of that library, because v2.5 is not downward-compatible.
That is annoying as fuck.
That's why you use virtual environments. You don't use a global shared library anymore, but a project-specific folder. So always when you start project A, it automatically loads the project-A-specific libraries (v1.2). When you switch to project B, it automatically loads the project-B-specific libraries (v2.5).
When sharing your project, you can simply provide a list with "Install library X in v2.5, library Y in v1.732.3 and library Z in v103.3-beta" for easy reproducibility. If you would always use your global-library, you would install A LOT of libraries, which you would not need for this project specifically, because your global library would contain ALL libraries from projects A, B, C, D and E. But you only need those for project A!
And this thing doesn't only affect the versions of libraries, you can even use different python versions. Project A uses python 3.11 and Project B uses python 3.14. You would have to adapt your command line all the time to use the correct python version for project A or project B. With a venv you just install a copy of this specific version in the project-specific folder.
2
1
u/unnamed_one1 7d ago
Disclaimer: I'm not an experienced dev, just a hobbyist, but I hope it helps anyway.
Think of a virtual environment as a sandbox with its own versions of python and packages.
When you install python on your computer, think of it as the global environment. Every package you install with pip3 will be available in this global environment.
But you can create additional virtual environments, which let you use different python and package versions.
It's good practice to use a virtual environment per project, because it allows you to make sure the python version and the versions of your packages for the project are exactly what your project needs.
2
u/Artistic-Army4423 7d ago
after reading all these answers, your concept are pretty solid. Thank you
1
u/Confident_Hyena2506 7d ago
If you don't have any python then you can't run any python.
And you will need lots of different versions of python for different projects - virtual env is just a way to organise them.
2
u/Artistic-Army4423 7d ago
alright, I feel it's kind of similar to node_modules in JS repos. Also, so there are other things as well which can do similar things, I will check them out
1
u/SharkSymphony 7d ago edited 6d ago
Yes, that's exactly what it is... but because it was added to the Python ecosystem as a third-party tool, you have to do a little more work (that `source venv/bin/activate` thing) to have Python and its tools use it.
(I guess if I'm being super-technical I'd clarify there's one difference between them – the ability for Javascript to work with different versions of the same library in the same node_modules, pulled in via different dependencies. With Python virtual environments, you're generally stuck with one version at a time.)
1
u/Discordbothost 5d ago
node_modules is a pretty good mental model. the main differences: a venv also pins which python interpreter runs, not just the packages, and python doesn't pick it up automatically from the folder like node does, you either activate it or point your editor at .venv. requirements.txt (or pyproject.toml) is the package.json part. if you want the npm-ish feel, uv does it: uv init, uv add requests, uv run main.py and it handles the venv for you
1
u/xaomaw 7d ago
If you don't have any python then you can't run any python.
I downvoted because of this.
If you install python, it is usually installed in Program Files or in AppData.
In the first place, this has 0% to do with virtual environments. You don't need virtual environments to run python at all.
1
u/Confident_Hyena2506 7d ago
Well if you didn't install python then you wouldn't have it - are you confused?
1
u/SharkSymphony 6d ago
Virtual environments don't manage installations of Python itself, only Python packages. We use other tools like pyenv (unfortunate naming collision!), uv, or pymanager to manage multiple installations of Python when we need them. (Or containers or VMs.)
1
u/Confident_Hyena2506 6d ago
All of those things are virtual environments, you are getting hung up on terminology.
There is a specific thing called venv yes - and many others.
On windows people have limited options tho. You missed out on "conda" as well - which is also better.
1
u/SharkSymphony 6d ago
No, one of these things is almost always what we mean when we say "virtual environment" in the Python community.
But you're right – conda is another option. I disagree that it's better, but I recognize its use in the Python data community.
1
u/Confident_Hyena2506 6d ago
It is better - the part you miss is that it's a general purpose thing and not a simple python thing. As in you can use it to setup your c++ env and other things.
On windows this is especially useful, because all the usual stuff like containers are useless on windows.
-1
u/Classic-Rate-5104 7d ago
Virtual environments have the drawback of encouraging the use of old (outdated) versions of packages, which in some cases can lead to serious security risks.
4
u/Confident_Hyena2506 7d ago
This is the case with software in general, so I'm not sure what your point is.
If you are referring to linux and it's integral python managed by system, then that is for the system not for your own projects - a point that causes much confusion.
It's just not correct that you can update your python to the latest and use that - this only works for trivial stuff - everything else has dependencies.
-1
u/Classic-Rate-5104 7d ago
Not completely true because i have seen many people building network services based on python packages with severe security problems in docker images. This is not strictly "system" but also not without risks
1
u/nekokattt 7d ago
How is this any different to any other programming language
-1
u/Classic-Rate-5104 7d ago
In other languages libraries have more stable interfaces but many python packages have a different interface every time you look at them. This makes this world more chaotic and unpredictable than other environments. Let me clarify, i like python very much but I wished its package-developers would be more aware of continuity and compatibility
1
1
u/SharkSymphony 6d ago edited 6d ago
We're getting a bit afield here, but I'd drink a soda to that. 😁
I do think there are a sizable number of Python packages now that get it right. But yeah, every long-time Python programmer probably has a list of minor-version-updates-that-weren't debacles etched into their brain.
1
u/rake66 7d ago
Not using virtual environments also has the drawback of encouraging the use of very new versions of packages, which in some cases can lead to serious security risks.
2
u/cdcformatc 7d ago
not using virtual environments also gas the drawback of having your shit break with no warning.
i was once working on a new project and installed some library which required an update of some dependency. then i went to work on a completely different project and to find out it was now broken because a library it used required a different version of that same dependency.
-1
u/Classic-Rate-5104 7d ago
You're absolutely correct. The whole python environment is very "unstable" in the sense that things change constantly. However, if possible, I would trust the debian packages more than the randomly chosen requirements.txt of many packages
2
u/nekokattt 7d ago
Thats fine until breaking changes occur in packages.
Relying on debian packages also removes any build reprodicibility on the basis that you have to always be running something with access to debian repos to be able to run your code in the first place.
1
u/SharkSymphony 6d ago
I don't think I'd agree with this. Yes, you have to consider your version management across projects, but virtual environments themselves don't have an opinion on what versions of packages you use. You can pursue a latest-and-greatest strategy with them as well.
1
u/Meta-failure 7d ago
Virtual environments started out as a way to make software work across different computers. Originally one dev would create software on their machine. But it wouldn’t run on someone else’s machine.
Virtual environments were the bridge here. If you create software in a vanilla sandbox from a code perspective, it has a much higher chance of running across on someone else’s machine when you go to deploy.
Are you already familiar with the differences between:
-the terminal.
-the interpreter.
-REPL
-the Python Kernel.
Understanding the sandbox itself and your coding environment will save you time in the long run.
Run these terms through copilot to learn about them before you jump in.
1
u/Discordbothost 7d ago
for the pycharm popup specifically: it just means that folder doesn't have an interpreter picked yet. click the create virtual environment suggestion (or bottom-right interpreter → add interpreter) and let it make a .venv in the repo using the python you already installed. after that, pip install -r requirements.txt (pycharm will often offer this) puts packages in that folder, not your system python. your node_modules analogy is basically right — selecting the interpreter is just telling pycharm to use this project's packages. if the repo already has a .venv or uses poetry/uv, pick that instead of making a second one.
1
u/sai_8303 5d ago
a separate environment per project keeps package versions from clashing and a simple requirements files makes any setup repeatble on another machine.Bootdev could help turn such habits into routine backend practice through short scripts rarely need full isolation
1
u/Solomoncjy 7d ago
Ok a virtual environment "venv" is basically a local store of installed pip packages for a specific project. This is done as some projects are incompatible with certain python versions and or packages, so a venv is used to manage them in a per project basis.
0
u/Educational_Virus672 7d ago
a venv(virtual environment) is like a city block sure it will work when eevrythign is far but a good and fast city block is somewhere where everythign is close liek your shops(libary),houses(code files) and leader/head(config)
note - forgot to mention it also helps you take away error/conflictc between different libary /files
-1
u/OkCaterpillar1058 7d ago edited 7d ago
To activate a virtual environment you can do:
cd project
source venv/bin/activate
If you want to make your own virtual environment
python3 -m venv venv
Then whatever packages you install, are only installed in that virtual environment, not system wide. The reason you do this, is to avoid conflicting packages. One project may need A 1.0 while another needs A 1.1 on the same system.
In PyCharm to change the interpreter:
Press Ctrl + Alt + S to open settings and then select Python | All Interpreters.
Select the interpreter and click Edit Interpreter… on the toolbar.
In the Interpreter Settings dialog, change the interpreter name in the Interpreter Name field or modify the target settings. Then click Save.
If I remember right, in PyCharm when you start a new project, it makes a virtual environment automatically. But I haven't used it in a long time
3
u/8dot30662386292pow2 7d ago
To activate a virtual environment you can do:
cd project
source venv/bin/activate
This only works if the venv already exists.
If you want to make your own virtual environment
Yes, you must make your own always.
python3 -m venv project
Per your last example this should be
python3 -m venv venv
And the name is often .venv, not venv.
1
u/fiddle_n 7d ago
Not to mention that all the instructions are Unix-specific - a significant number of users, especially beginners, use Windows for Python
-1
u/5960312 7d ago
Your virtual environment is an alternative location where your programming profile will live. So instead of saving everything in the your C drive you can set up a new desktop so to speak within your drive that you only use for programming. If you don’t set up a programming environment then anything you create or download will save to your root drive and that’s obviously bad for security.
0
u/Classic-Rate-5104 7d ago
Virtual environments have the drawback of encouraging the use of old (outdated) versions of packages, which in some cases can lead to serious security risks.
1
u/nekokattt 7d ago
They do not encourage this at all, they encourage you being able to reproduce builds.
Just because people do not maintain their projects properly does not mean it is anything to do with virtual environments. Don't use them and just use the system site-packages and you will still have the same issue.
1
u/fiddle_n 7d ago
What are you proposing as an alternative? Always using the newest package version? That comes with stability and security issues.
1
u/Classic-Rate-5104 7d ago
If possible, use the stable packages of your distribution, if that's not possible you don't have another choice than virtual environments
9
u/SharkSymphony 7d ago edited 7d ago
A virtual environment is:
- a custom-made directory you can install Python packages into
- a mechanism for making sure Python and its packaging tools use that directory when it runs
When you do that, Python will use both system-installed (i.e. global) packages and packages from your virtual environment when it runs.
This allows your project to install and manage the packages it needs separately from other projects you have. It may not be all that useful when you're just getting started, but it's almost essential for those of us working on dozens of different projects at various states of development. We typically leave the system installation pretty bare-bones when we're working with virtual environments.
One problem with virtual environments, beyond it being one more thing you have to manage, is that all the Python tools your project uses have to use that virtual environment when they run Python, or your project will be missing packages it needs! But with PyCharm it's easy: you just point it to one you've already created, or have it create one for you.
Alternatives to virtual environments include:
- Multiple Python installations on your machine
- Using Docker containers for your projects, each with their own Python installation
- Using virtual machines for your projects, each with their own Python installation
There are times when you want that added isolation, but for development, virtual environments are way less hassle in most cases.