@RomanOnARiver
Then it's like @diazona said, the "hip" way is to use a virtual environment.

You can use `python -m venv` to create one, but you might want to take the opportunity to learn one of the project-oriented tools like PDM or Poetry. Then it's just a simple `pdm add wxpython` or `poetry add wxpython`.

An advantage of these tools is they'll record the exact versions of all packages they install, so when you return to the project it'll still work exactly as you left it.

@RomanOnARiver @dragon0 You need to run the python from that virtual environment. (There are a few packages that are written to allow them to use things from other virtual environments, but that's quite rare.)

But note that if you have a Python script (a .py file) sitting somewhere on your system, that script doesn't inherently belong to any virtual environment. It's the Python *interpreter*, and installed packages, that belong to virtual environments. If you just have a script file, you can use an interpreter from any virtual environment to run it. It may do different things depending on which interpreter you use. (Like, usually, failing with an error if the script uses some package that isn't installed in that particular virtual environment.)

#Python

@RomanOnARiver @dragon0 Yes, exactly. You would run `/foo/bar/python script.py`.

Note that if you're working on Linux or similar, it would be unusual to create a virtual environment somewhere you needed to use `sudo` for it - like /foo - unless you're specifically installing something meant to be used system-wide. (Not very common.) Virtual environments are lightweight, they're meant to be created and deleted over and over again as needed, so it's not like you have to put them somewhere "permanent".

#Python

@RomanOnARiver @diazona

These tools generally put the venvs under ~, so dist upgrades shouldn't touch them

@RomanOnARiver @dragon0 It'd probably work for most things. You could definitely try, at least.

I think the most likely way for you to run into a problem there is if you want to install two different packages that require different versions of some dependency. Like, say, if you install one thing that requires appdirs at most version 3, and another that requires appdirs 4. (Totally made-up example, of course) They can't both be installed at the same time in the same virtual environment, so then you'd have to split those two things apart.

You'd probably also have a hard time figuring out if you can safely remove a package from your mega-venv. (Though there are ways around that, by recording what you installed and why - tools like pipenv, pdm, poetry, etc. can help with that)

#Python