Hey smart people of the Internet. It seems like things have changed (for the worse) in newer #Python. I am trying to install #wxPython like I always have been doing, per https://wxpython.org/pages/downloads/

pip install -U -f https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-24.04 wxPython

And it is suddenly yelling at me to not install the exact way I have been installing this for years and years. What is the new cool hip way they want me to do this? Preferably uncomplicated. #ubuntu #gnu #linux #programming

wxPython Downloads

Current Release Starting with wxPython 4.0 (the first Phoenix release) the wxPython source archive and, for supported platforms, wxPython binary wheels are available from the Python Package Index (PyP

wxPython
@RomanOnARiver
What's the output from that pip command?
@dragon0 thanks for responding. The error is "externally-managed-environment" asks me to use apt which wouldn't get me the latest version I want

@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.

@dragon0 @diazona so if I'm installing some module in a virtual environment is it accessible from any python script on the system or do I need to run python from inside that virtual environment?

@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

@diazona @dragon0 gotcha, so if my virtual is in /foo/bar/python as opposed to my global /bin/python or wherever they put it, I'm running /foo/bar/python and my script can be anywhere, if I'm understanding correctly.

@RomanOnARiver
That's correct.

If you want to have "global" environments, you might want to use an env wrapper like virtualenvwrapper. Rather than per-project venvs, these tools make named venvs in a well-known directory. You can then set the #! line in your scripts to use a specific venv for that script (eg #!/foo/bar/python at the top of the script).
@diazona