make install in criu 3.19 creates crit 3.18 wheel

[dilyanpalauzov]

Running make install in criu 3.19 prints

Successfully built pycriu                                                                                                               
Installing collected packages: pycriu                                                                                                   
Successfully installed pycriu-3.19                                                                                                      
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It i
s recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv                                                   
  INSTALL  crit                                                                                                                         
Processing ./crit                                                                                                                       
  Installing build dependencies ... done                                                                                                
  Getting requirements to build wheel ... done                                                                                          
  Installing backend dependencies ... done                                                                                              
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: crit
  Building wheel for crit (pyproject.toml) ... done
  Created wheel for crit: filename=crit-3.19-py3-none-any.whl size=5045 sha256=743276241c6bea8ac2ad5de0908572541d9504c30ac9e1b0dc94bdec54dc7e00
  Stored in directory: /tmp/pip-ephem-wheel-cache-ngzsjm_s/wheels/3e/b7/00/3ecbf1fe65764793abc5cce7c0bed93ee1f16622808ec47e5a
Successfully built crit
Installing collected packages: crit
Successfully installed crit-3.18
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
make[2]: Nothing to be done for 'all'.
make[2]: Nothing to be done for 'all'.

Before I had crit 3.18 installed.

Why the above excerpt contains Successfully installed crit-3.18 and pip list|grep cri shows

crit 3.18 pycriu 3.19

when I am installing criu 3.19?

[dilyanpalauzov]

The initial subject was misleading. Corrected to

make install in crio 3.19 creates crio 3.18 wheel

[rst0git]

@dilyanpalauzov Would you be able to confirm what version is specified in the Makefile.versions file?

[dilyanpalauzov]

I download http://github.com/checkpoint-restore/criu/archive/v3.19/criu-3.19.tar.gz , mentioned at https://criu.org/Main_Page . It does include Makefile.versions, identical to https://raw.githubusercontent.com/checkpoint-restore/criu/v3.19/Makefile.versions .

[rst0git]

A similar problem has been previously reported in https://github.com/pypa/pip/issues/3049

Before I had crit 3.18 installed.

I would recommend to uninstall the previous version(s) of pycriu/crit before running make install, then to confirm the installed versions with:

crit --version
criu --version

[dilyanpalauzov]

Eventually both 3.18 and 3.19 version is installed

/usr/local/lib/python3.10# find|grep crit
./site-packages/crit-3.19.dist-info
./site-packages/crit-3.19.dist-info/RECORD
./site-packages/crit-3.19.dist-info/INSTALLER
./site-packages/crit-3.19.dist-info/direct_url.json
./site-packages/crit-3.19.dist-info/entry_points.txt
./site-packages/crit-3.19.dist-info/METADATA
./site-packages/crit-3.19.dist-info/WHEEL
./site-packages/crit-3.19.dist-info/REQUESTED
./site-packages/crit-3.19.dist-info/top_level.txt
./site-packages/crit
./site-packages/crit/version.py
./site-packages/crit/__pycache__
./site-packages/crit/__pycache__/__main__.cpython-310.pyc
./site-packages/crit/__pycache__/version.cpython-310.pyc
./site-packages/crit/__pycache__/__init__.cpython-310.pyc
./site-packages/crit/__init__.py
./site-packages/crit/__main__.py
./site-packages/crit-3.18.dist-info
./site-packages/crit-3.18.dist-info/RECORD
./site-packages/crit-3.18.dist-info/INSTALLER
./site-packages/crit-3.18.dist-info/direct_url.json
./site-packages/crit-3.18.dist-info/METADATA
./site-packages/crit-3.18.dist-info/WHEEL
./site-packages/crit-3.18.dist-info/REQUESTED
./site-packages/crit-3.18.dist-info/top_level.txt

So the problem with the installation procedure is that it does not uninstall crit 3.18 before installing crit 3.19.

When I do:

# pip uninstall crit
Found existing installation: crit 3.18
Uninstalling crit-3.18:
  Would remove:
    /usr/local/bin/crit
    /usr/local/lib/python3.10/site-packages/crit-3.18.dist-info/*
    /usr/local/lib/python3.10/site-packages/pycriu/*
  Would not remove (might be manually added):
    /usr/local/lib/python3.10/site-packages/pycriu/images/core_loongarch64_pb2.py
    /usr/local/lib/python3.10/site-packages/pycriu/version.py
Proceed (Y/n)?
  Successfully uninstalled crit-3.18

I actually see that the 3.19 files are not touched. And indeed now without installing anything

# pip list|grep crit
crit                          3.19

To reinstall pycriu, I call again make install.

So the suggestion to pip uninstall crit 3.18 before make install in 3.19 is good, but this process is very, very unusual when installing from source code.

[dilyanpalauzov]

As an example, I have the repositories of mailman, postorius, hyperkitty. When I want to upgrade the software after git pull, I do pip install -U .. Then the old version is somehow replaced (thus first removed) with the new version. I do not know how the criu install process is organized, but calling something like pip install -U . shall solve this trouble in the futire.

[rst0git]

Eventually both 3.18 and 3.19 version is installed So the problem with the installation procedure is that it does not uninstall crit 3.18 before installing crit 3.19.

Yes, that is correct. pip can install multiple versions of the same module. To uninstall all versions, you would need to run pip uninstall multiple times, once for each version.

calling something like pip install -U . shall solve this trouble

It is slightly more complicated. The -U (or --upgrade) option for pip install does not uninstall previous versions because we also specify --prefix. In particular, the function get_dist_to_uninstall(), which is used to check if there is already an installation under the same module name, returns None. In addition, some distributions such as Fedora and CentOS apply a patch that explicitly prevents -U from uninstalling packages in /usr/lib.

[dilyanpalauzov]

pip can install multiple versions of the same module.

Where is this information from? https://skippd.medium.com/handling-multiple-versions-of-a-package-in-python-73055998ce73 says the opposite:

If you’ve used pip, you know the problem, it dosen’t support multiple version. If you try to install another version of package, it will replace the previous version instead of keeping both.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.