ModuleGuard

Motivation Examples

Example 1-- Overwriting module

The project ysr-monitor@0.1.5 has two dependencies board@1.0 and adafruit-blinka@8.20.1 in its dependency graph, which means that they will be installed simultaneously when downloading the package ysr-monitor@0.1.5 using pip. The problem is that pip installs them to the same target, and the board.py modules will be overwritten. This behavior leads to errors that are difficult to debug, especially in CI/CD environments. Fixing the problem requires a time-consuming effort to find the overwritten module and then reinstall the package it belongs. This act of installing the package has a high risk of corrupting the local environment and eventually causing irreversible errors.

As shown by the image, the board.py module exists in both packages and does not have the same hash value. When the installation completes, an overwrite issue occurs, i.e. the board.py of the adafruit-blinka@8.20.1 package overwrites the board.py of the board@1.0 package.

Example 2-- Importing confusion

The two packages jwt@1.3.1 and pyjwt@2.6.0 are installed in the two different targets (e.g. one is installed in the system site-packages path and one is installed in the virtualenv site-packages path.). However, they both have the jwt/exceptions.py module, which will conflict when importing. Two different modules have the same relative path, so the wrong module may be imported, and the search order is based on the path order in sys.path. Fixes for this issue often require the deep experience of developers and require a change in the order of system environment variables or using absolute paths to import modules, which is inconvenient.

As shown jwt@1.3.1 is installed in the system's Python environment and pyjwt@2.6.0 is installed in the virtualenv virtual environment. The actual import in Python will be due to incorrectly importing the jwt/exceptions.py module of the pyjwt@2.6.0 package, which does not have a PyJWTError function.

Page updated

Google Sites

Report abuse