In this SO post I outlined my problems, and I would like to try and solve them by getting rid of all my downloaded python launchers, modules, versions, pip etc (for python 2 & 3) and start afresh. My only problem is that macOS comes pre-loaded with python 2 and I don't think I can or should get rid of that, but I do have other versions of python 2 installed that I do want to delete.
Is there any help that you can offer that will tell me what to delete and what not to?
Should I need to use 'sudo' at all during my uninstalling?
Are there any tests to ensure certain things are completely gone?
Please keep answers fairly simple to understand implement.
When I reinstall the things I need, is it better to do it all via home-brew, then pip; instead of downloading from safari, unless necessary?
If you installed using sudo (or typed your password into an installer), you'll need this to uninstall too. Mac python is in /usr/bin/python and /usr/lib/python*. Yes it can be good to install via homebrew, although I've had good success with the Anaconda distro of Python. The important thing is setting you PATH and PYTHONPATH variables in ~/.profile or ~/.bash_profile so that it sees your custom installed Python before it sees the system install.
Related
I tried to update Python 3.8.5. to 3.8.10 on a Windows 7 machine, but some part of Python's and/or pip's messy installer/path/package management system bricked everything. Nobody I asked knows a canonical solution to this + pretty much everybody is suggesting a complete reinstallation.
Which is why I've now completely removed Python and have to reinstall Python, pip, and all my packages one by one. I've already uninstalled/removed Python and pip and downloaded the official Python 3.8.10 64-bit Windows installer as well as get-pip.py.
But despite spending days and days of reading, I can't see through Python's complicated mess of "user-specific vs. local vs. system-wide" installation schemes, varying package installations paths, the seemingly arbitrary variations introduced by using python vs. python -m, pip install vs. pip install --user etc. during package installations, and the regular whining about some PATH environment variables not being set properly etc. pp. - if you've ever used Python professionally, you'll have an idea of what I'm describing here.
Anyway - what I want to do now is make one clean installation where I stick to one set of rules for everything. All packages installed to one single superdirectory (vs. getting scattered all over the system) and all PATH variables set accordingly to the most universal and complete configuration possible (I don't want to see any complaints from Python ever again in this regard). Note that I'm the administrator of the machine, but working from a normal user account with Windows UAC enabled and want an installation for all users - the most general solution possible, no limiting scenarios that may cause the very problems I'm trying to avoid.
Also, I do not want to use virtual environments for now, but this is different topic I'm already working on independently. So no suggestions regarding venv.
Question: How to procede with the installation?
Possible sub-issues that need to be addressed:
Correct privileges for the Windows installer, e.g. the confusing "for all users (requires elevation)" and subsequent (second!) "Install for all users" options. The latter changes the installation path from C:\Users\<Username>\AppData\Local\Programs\Python\Python38 to C:\Program Files\Python38 and Windows UAC may prevent access of Python and/or pip to C:\Program Files\ without proper exception handling (e.g. user prompt) in place:
Usage of get-pip.py vs. some other methods to install pip, which also concerns the usage of python vs. python -m vs. pip install vs. pip install --user etc. in this context and subsequent installation of user packages.
Prevention of scattering/fragmentation of the Python development framework over the system/different folders/different users, causing e.g. annoying PATH or dependency issues/conflicts.
Defining the correct set of Windows path variables under these requirements and addressing concerns/doubts about Python's and pip's ability of reliably handling this issue on their own.
Note: I'm the owner/only user on this machine and therefore have administrator rights. Managing installations/environments for multiple users is not the subject here and of no interest for me.
Anyway - what I want to do now is make one clean installation where I stick to one set of rules for everything. All packages installed to one single superdirectory (vs. getting scattered all over the system) and all PATH variables set accordingly to the most universal and complete configuration possible (I don't want to see any complaints from Python ever again in this regard).
This is contradictory. A single installation with a common set of rules, every possible installed package, comprehensive PATH etc. is inherently not "clean". The point of maintaining separate installations is so that one user's changes do not unexpectedly impact on the operation of another user's code. It is not possible to do this with a single installation. If you upgrade a library, for example, it affects every user who wrote code that uses that library, who must now check for incompatibilities.
Correct privileges for the Windows installer, e.g. the confusing "for all users (requires elevation)" and subsequent (second!) "Install for all users" options.
The first one means "Install the launcher for all users", which is why that checkbox is on the same line as "py launcher". (If you are not familiar with the Python launcher for Windows, please read the documentation.) it says "(requires elevation)" because the installer requires elevation in order to install this feature for all users. You do not need to do this if you have installed it from a previous version of Python.
and subsequent (second!) "Install for all users" options.
This is the option to install this version of Python for all users. The install directory changes according to the "for all users" setting, in the expected way.
Windows UAC may prevent access of Python and/or pip to C:\Program Files\ without proper exception handling (e.g. user prompt) in place
It will prevent write access without elevation, yes. This is by design, and it is why the option exists for per-user installations.
pip requires write access, because its purpose is to install libraries. I do not know whether it can request elevation from the command prompt; probably not. You can work around this by using the command in an elevated command window. With UAC enabled, you will not be able to install libraries into a Python for-all-users installation (i.e., in Program Files): it is the explicit purpose of UAC to prevent that sort of thing.
Python normally does not require write access to these directories. The standard library does not need write access once the library is installed. There might be a problem if you uncheck "Precompile standard libraries"; I have not tested this and have stopped using Windows. Third-party libraries normally will not require write access for their own installation directories, either. If you encounter a problem, consult the documentation for that library.
Usage of get-pip.py vs. some other methods to install pip, which also concerns the usage of python vs. python -m vs. pip install vs. pip install --user etc. in this context and subsequent installation of user packages.
get-pip etc. are deprecated. They are tools intended to account for the fact that Python didn't always come bundled with pip. It does now. pip works the same way regardless of whether it was bundled with Python or installed to an older Python version separately. There is not a clear question here; there are several specific things that need to be researched and understood about how to use pip.
I currently have a rather complex Python configuration that has evolved over the years, and I'd like to clean it up and "modernize" it.
The existing configuration has a the default macOS Python, and Homebrew's Python 3 and Python 2 all existing side-by-side, along with their associated Pips. I also have some python command line tools that these Pythons or their associated installed packages have created, and which I use more or less frequently.
What I'd like to do is:
Leave macOS Python untouched
Eliminate all Homebrew Python's
Remove non-macOS Python 2 entirely
Switch to Conda Python as my Python 3
Have access to mkvirtualenv (as an alternative to creating environments) with virtualenvwrapper
Have access to Jupyter
I'm not sure how to do this without creating problems, and want to confirm that the obvious thing is the safe thing:
use Homebrew to uninstall its Pythons,
install Conada, and then
use (Conda's) pip to install mkvirtualenv, virtualenvwrapper, and Jupyter (and any other tools I subsequently need)
Is that the correct procedure? Is so are there particular forms of the commands I should use or options I should chose for them?
The biggest and/or first issue is how to not break existing functionality that relies on Python. There are two broad camps here:
1) tools and other scripts that hard-code the Python executable's location, and
2) tools and other scripts that rely on the/a system PATH variable.
#1 is the easier one. If you aren't going to remove any Python versions, then these are no work at all...these will keep working. If you do want to uninstall some Python versions, then you have to work to switch any tools relying on those versions you want to remove to another version that also works for that tool. The path in question is commonly in a shebang ('#! xxx') line at the top of each main Python binary, but there are other ways that the path to the Python binary can be formed. In short, why uninstall anything? Disk space is cheap. Maybe instead just make sure that these unwanted versions are not referenced by any PATH variables.
#2 is the hard one. It isn't necessarily the case that all of the tools in this category are using the version of Python you get when you just type "python" at a command prompt for your primary account. There can be other modes of operation that initialize the execution environment (the PATH variable) in different ways, and so may be running different Python versions despite depending on the value of PATH.
Part of #2 is worrying about not just "python" references, but "python2", "python3", and possibly other variants as well.
Only once you've got a plan for dealing with the above so you don't break things can you worry about possibly getting rid of Python versions and installing new ones. Hopefully, Brew does a good job of uninstalling the versions it's installed, so if you can remove dependencies on one or more of them, they can potentially be easily removed. If you've got self-installed Python versions, those should be easy to uninstall as well by just removing references to them in PATH variables (or not...shouldn't be a big problem if you miss some) and then deleting the install directory.
Then there's adding the new version(s) of Python. This can only affect #2 above. You have to think about that one and know what affect you're going to have if the new install(s) manipulate any PATH variables. If it only manipulates your own user's PATH, or it leaves it to you to do so, this is a much easier to understand task, but any change to the environment is a chance to break existing functionality.
Finally, there's the mechanisms for choosing different Python versions for new development, including the use of virtual envs. This is probably the easiest part, as you can do research, try things, and test that you can do whatever you want to do. This part of the problem is the best bounded.
I don't know anything about Jupyter, other than knowing vaguely what it is, so I don't know how that complicates all this.
UPDATE: A final note. As you may already know, Python does a good job of isolating itself in terms of each version keeping its unique identity. If you use the right 'pip' and 'easy_install' that are sitting right next to the 'python' binary you're going to run with, you should be cleanly affecting just that one environment. I can't know that it's this easy for all Python versions, but I've never seen this convention broken by a version of Python that I've used. The complications here, of course, involve which versions of these tools you're getting in various situations when they are found via a PATH variable.
First, install anaconda or miniconda. The installation is non-destructive and does not conflict with your other Python installations. Check that it works before you consider removing homebrew installed Pythons.
The conda command is used both as a package manager and as an environment manager. You cannot avoid creating conda environments: the default installation is already part of an environment named base. I'm not sure why you would want to, either.
You can use pip to install any package you choose into a conda environment, but since you can use conda install for any package available on any conda channel (e.g. 'defaults', 'conda-forge'), using pip often is redundant.
You could use non-conda virtual environments, but again: why? conda create -n foo python=x.x jupyter #etc and then conda activate foo is all you need to get one up and running.
I don't know how I've gotten here but I have many competing installations of python on my Ubuntu 16.04 path. Some I use, some I don't.
I'm at the point now where I want to clean up things to save headache when troubleshooting issues but I don't know any strategies or tools of tackling this.
What is the best way I can find out which environments are being used and not used?
How can I determine which python directories are being pointed to and which ones are abandoned?
Whats a quick way I can get a list of non-standard packages installed to each environment?
Here is what you can try
which python usually for python2.x and which python3 for python3.x.
Then decide which version you want to use by default then you can use export python='Your required python interpreter path' for permanent changes, or you can use alias python=PATH for temporary usage.
Also see where the pip and pip3 are pointing at by using which pipX. Thus you can use one of them to install required packages.
I would recommend you to use virtualenv or pipenv so that you get more fine grained control over the interpreter selection according to the need of your project.
Note do not uninstall any of the above python packages without some research as there might be system dependencies thus breaking your system.
I'm running openSUSE 13.2. I already had python 2.7.8 and python 3.4.x. I ran into a situation where a business server was running python 2.6. I wanted to make a virtualenv, but I need to install the specific version first. I couldn't find python 2.6 in yast and I wasn't getting any hits when I was search for stuff in zypper.
So I downloaded the tar ball from python's download page for python 2.6.6 and followed the directions in the readme
./configure
sudo make install
This worked, but it changed my default python interpreter in the process. I worked through that and now things are fine. But I might want to install a different python version in the future without having to worry about it changing my default interpreter. I'm pretty sure there's more I could do on my own, but I need to move on to something else and I'm wondering if anybody was some quick feedback on what I've done so far and what I should do in the future.
If you need to maintain distinct versions simultaneously, it's best to install each in its own tree. configure takes an optional --prefix=/path/to/installation/root argument.
At one site, we would install an add-on software package in something like /opt/local/x86_64-linux-gnu/python-2.6.6. Users who need this specific version can then add /opt/local/x86_64-linux-gnu/python-2.6.6/bin to their $PATH, or use virtualenv or GNU stow.
I've been going with a basic Python3.4 install that I've been installing many modules into for over the past month but have reached a point where pip is coming up short and I'm going to just install the full Anaconda on my system to go deeper into bokeh-server stuff.
I get a popup during the Windows 64bit installer (Anaconda3-2.3.0-Windows-x86_64.exe) saying
A version of Python 3.4 (64-bit) is already at C:\Python34\ We
recommend that if you want Anaconda registered as your system Python,
you unregister this Python first. If you really know this is what you
want, click OK, otherwise click cancel to continue.
Didn't find much documentation on this subject, and I'm not really sure how to "unregister" that installation of Python apart from uninstalling it entirely from Windows which I imagine would accomplish such a thing. Is this basically telling me to check how my Python Launcher for Windows is setup after the Anaconda installation? I'm completely unfamiliar with this notion of python system registration? Is that just a round about warning about which python version takes precedence on the system path, or which installation holds the file associations?
The solution is simply to uninstall python (for example, run the original python installer and select the uninstall option). The python key in the windows registry will be removed (which is what unregister means in this context).
Here is a link to a script that will unregister a Python installation (if you haven't come across it already). I personally have not dealt with anything like this. It seems like it should work, but you may have to tinker around with some of the paths in the script to get things to work. The links in #nightuser 's post will also probably fix the issue.
Why not just remove your version of Python? You could do a pip freeze > requirements.txt with your current Python and add them to Anaconda, or create an environment with Anaconda using those packages. Anaconda has greatly decreased the amount of time I spend setting things up.
You are getting that prompt because you have another version already installed the safe way to do this is going to the directory of the existing version and running the uninstaller. Once the previous version is completely uninstalled. You can run the installation as normal it should works!
enter image description hereYou have already installed python in your environment, so your system can handle your python code. Anaconda can handle your python code as well. If you install Anaconda and expect use python provided by Anaconda, then your system will confuse about assigning the code job. To avoid this confusion, there is always a path to point out which python you want.
You can ask your OS to find specific python by changing your environment path in windows OS:
By deleting the python path your Python will be invisible. Changing path is more convenient compared with the uninstall.
If you got a python compiling software like Pycharm, things are different. Pycharm may have python3.6 while your system got python 3.5. You need to delete path in those software or uninstall python specified by those software.
Pycharm
Actually, instead of registering the Anaconda as the system python, you can install it first, then specify your Pycharm and system path to the Anaconda python path. Thus, your Pycharm will use python provided by Anaconda and package & virtual environment you need.
I edit this for lots of times because I got Great wall, so I can't close something pop up in my screen(cause it is Blank). And everything is missing if I refresh. This is annoying.
My system path Anaconda3's python36
Add path in Pycharm
Or you can't use these packages and Anacon's virtual Environment