@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