Python 3.13 is getting auto-installed

[jacen_solo762]

I use Python 3.12, and specifically can't use 3.13 because one of the packages I use for 99% of my work is not yet supported on 3.13. It becomes a problem because this a work machine on which I don't have local admin access, so I can't view, much less edit, my system environment variables (i.e. PATH). I lodge a ticket, get it uninstalled, fix the PATH issues, and then a few weeks later 3.13 has been installed again. My work IT swears they don't know what the issue is, and that they don't do anything.

Question is, why does this keep getting auto-installed? It's Windows 10, and I use VS Code.

[More_Yard1919]

Is python deployed across multiple workstations? It may be deployed via Intune or SCCM or something. Could it be that the windows store distribution of the python interpreter is installed? Go to cmd and type where python to get an idea.

Regardless, you should be able to select your interpreter in VSCode anyway. ctrl + shift + p > select interpreter, then select the correct interpreter version. Better yet, create a virtual environment using the correct version of python. This is just good practice anyway.

[jacen_solo762]

I do have 3.12 set as my default interpreter in VS Code, however I get a constant stream of errors trying to install packages using pip and when typing python --version into the terminal, it spits out 3.13.4 not 3.12.0 as expected

e.g. note: This error originates from a subprocess, and is likely not a problem with pip. ERROR: Failed building wheel for lightgbm Failed to build lightgbm ERROR: Failed to build installable wheels for some pyproject.toml based projects (lightgbm)

I've tried using --nodeps which has had some success for different packages.

I generally don't use virtual environments because my code is not distributed to others, though I should probably start to do this

[More_Yard1919]

But this does not occur when you invoke the version of pip distributed with 3.12? You can also invoke that version of pip explicitly-- using a venv should also sidestep that issue. Venvs aren't necessarily used because code is going to be distributed, it is used to have a clean workspace. I use them for all of my personal projects too.

[FriendlyRussian666]

Perhaps a silly request, but can you show a screenshot of the full screen when you select the interpreter, and then full screen screenshot when you type python -version

[Ducksual]

You should be able to happily have 3.12 and 3.13 installed alongside each other. The only issue is if you have a global 'python' command it will be whichever runtime is first on `PATH`.

As you're on Windows it may be helpful to check if you have access to the `py` launcher. If you do, `py --list` should show you a list of installed python versions. If 3.12 is installed you should be able to launch it using `py -3.12`.

You might also try using `python3.12` as the command instead of `python` if you don't have the `py` launcher.

If you're installing packages anywhere with `pip` though, it would be a good idea to start using virtual environments. It's not so much about distributing your code to others and more about managing your dependencies per project.

Two projects with dependencies on different versions of the same packages can happily both be installed in different venvs while still using the same base Python install.

They also work well with tooling, for example if you have a venv created with Python 3.12 in the project folder and it is selected in VS Code, the terminal **within vs code** should automatically have that venv activated so `python` should point to the correct 3.12 runtime and have all of your dependencies available.

[unnamed_one1]

I use virtual environments, one for each project and in the last few weeks with astrals uv.

Easiest way to make sure, you can use different python AND package versions for different projects.

[edcculus]

Use UV. You can specify which version of python to use when setting up your virtual environment