![]() ![]() Python: Publishing and Consuming from RabbitMQ using Python.Python: Setting the preferred Python version on Bionic 18 and Focal 20.Where python will look for packages, link python3 -c "import sys print('\n'.join(sys.path))" Python3 -c "import sysconfig print(sysconfig.get_paths())" Sudo update-alternatives -remove-all python3Ĭhecking library directories python3 -c "import sysconfig print(sysconfig.get_paths())" Sudo update-alternatives -remove python3 /usr/bin/python3.9 If you want to remove alternatives sudo update-alternatives -remove python3 /usr/bin/python3.8 Stackoverflow, how ‘dist-packages’ is a Debian specific convention Github pyenv-pip-migrate, project for migrating pip modules Stackoverflow,com, migrate site package modules installed with pip from older to newer versionį, python setting the preferred version using update-alternatives Stackoverflow, how to move all modules to new version of python Pip3 list -user -v | grep "$new_version"įoo=BAR python3 -c 'import simple_env as se print(se.get("foo"))' # now modules present in newer 'site-packages' usr/bin/$old_version -m pip list -v | grep -v "$HOME" | grep $old_version | awk -F' ' '-freeze.txt # capture name and version of modules used by older version ![]() # show list of system modules, notice no modules coming from newer python # test module no longer works with newer Python (ModuleNotFoundError) # verify that pip is using the newer version # verify we are using the preferred newer version those installed by apt) to be installed at the system level in the shared “/usr/local/lib/python/dist-packages” directory. Python3 -version Migrating the System level Python modulesĪlthough virtualenv and user level modules are the preferred way of installing Python modules, it is not uncommon for some modules (e.g. # verify that python3 points to newer version # we can see managed link now points to /etc/alternatives/python3 ![]() ![]() Sudo update-alternatives -install /usr/bin/python3 python3 /usr/bin/python3.9 20 Sudo update-alternatives -install /usr/bin/python3 python3 /usr/bin/python3.8 10 # If so, remove default symbolic link so we can use alternatives instead # does system already have link for 'python3'? You could create your own symbolic links, but on Debian/Ubuntu the ‘ update-alternatives‘ is the preferred method of administration. Now that we have two different versions of Python on the host, what we need is a way to assign a default ‘python3’ to point to the newer one. # verify it is installed into older python 'site-packages'įoo=BAR python3 -c 'import simple_env as se print(se.get("foo"))' Use ‘update-alternatives’ to manage preferred version Install test module at User level # install User level module as test Python3 -c "import string_utils print(string_utils.is_string('hello'))" # verify it is installed into older python 'dist-packages' Install test module at System level # install System level module as test Using the default older Python version, let’s first install some small test modules at the System and User level that can serve as markers of our success later. usr/bin/python3.9 -version Install System and User level modules for testing migration # install Python 3.9 (3.8 will still remain) # verify that 3.9 is available for install This does not wipe out or remove the older version, they will both exist in parallel. Note that ‘dist-packages’ is a Debian/Ubuntu convention.įor this article, let’s assume that we started with Python 3.8 (/usr/bin/python3.8) installed as the default on Ubuntu 22.04, and then we installed a newer Python version 3.9 as well (/usr/bin/python3.9). This article will show you how to capture the module name and version used by the older Python version, and use that to install matching modules to the newer version’s dist-packages/site-packages directory. But there is still the matter of Python modules installed at the System level (dist-packages) as well as User level (site-packages) that can be affected by a Python upgrade. Hopefully you are using venv at the individual project level, which will avoid most problems since a specific Python version and set of modules is explicit. But you most likely have pip modules installed at a version specific ‘dist-packages’ or ‘site-packages’ directory, and those modules have to be freshly installed into the newer version if you want the same behavior. Migrating from one Python 3.x version to a newer 3.x minor version seems like it would just be a simple ‘apt install’ of the latest Python package. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |