Dependencies in requirements.txt have module conflicts.

[unsatisfying]

Background

Dependencies in requirements.txt have module conflicts.

Description

There are two dependencies mentioned in the requirements.txt file: pysoundfile and soundfile. These two packages (pysoundfile and soundfile) are both the audio library based on libsndfile. They share many modules (with different contents). During the pip installation process, both of these packages will be installed simultaneously. However, pip does not isolate these two packages, but rather installs them both in the site-packages directory. This leads to the situation where modules from the later installed package overwrite the modules with the same paths installed by the earlier package (e.g. soundfile.py).

Steps to Reproduce

pip install -r requirements.txt

Desired Change

Indeed, it is not an ideal behavior for modules to be overwritten, even if they are not actively used or if the overwritten module is the one being called. It introduces uncertainty and can cause issues in the long run, especially if there are changes or updates to the overwritten modules in future development. It is generally recommended to avoid such conflicts and ensure that only the necessary and compatible dependencies are declared in the requirements to maintain a stable and predictable environment for the project.

We believe that although this project can only modify direct dependencies and indirect dependencies are a black box, it is possible to add additional explanations rather than directly declaring both conflicting packages in the requirements.txt file.

Adding extra explanations or documentation about the potential conflicts and the need to choose only one of the conflicting packages can help developers understand the issue and make informed decisions. Including a clear instruction or warning in the project’s documentation can guide users to choose the appropriate package based on their specific requirements.

[rsxdalv]

This breaks the environment when installing this project. It creates a very confusing situation where you check your 'soundfile' and get the right version but because of a rogue pysoundfile you actually have 0.9.
I see no reason for both pysoundfile and soundfile, so I will make a PR without pysoundfile.

[unsatisfying]

This breaks the environment when installing this project. It creates a very confusing situation where you check your 'soundfile' and get the right version but because of a rogue pysoundfile you actually have 0.9. I see no reason for both pysoundfile and soundfile, so I will make a PR without pysoundfile.

Thank you for your reply and I'm glad our research has contributed to the stability of your project.