Closed NeolithEra closed 4 years ago
Hi, This is a very good point. The problem we encountered was a compatibility issue between script and h5py (if I recall correctly). The easiest is probably to go with option 3 for now. But I will have a closer look, to resolve the compatibility issues and loosen the version requirements.
Hi, as shown in the following full dependency graph of episcanpy, episcanpy requires scipy <=1.3, episcanpy requires *_seaborn _ (seaborn 0.10.0 will be installed, i.e., the newest version satisfying the version constraint), and directed dependency seaborn 0.10.0 transitively introduces scipy >=1.0.1. Obviously, there are multiple version constraints set for scipy in this project. However, according to pip's “first found wins” installation strategy, scipy 1.3 (i.e., the newest version satisfying constraint <=1.3) is the actually installed version. Although the first found package version scipy 1.3 just satisfies the later dependency constraint (scipy >=1.0.1), such installed version is very close to the upper bound of the version constraint of Scipy specified by seaborn 0.10.0** .
Once seaborn upgrades,its newest version will be installed, as episcanpy does not specify the upper bound of version constraint for seaborn. Therefore, it will easily cause a dependency conflict (build failure), if the upgraded seaborn version introduces a higher version of Scipy, violating its another version constraint <=1.3. According to the release history of seaborn, it habitually upgrates Scipy in its recent releases. For instance, seaborn 0.9.0 upgrated Scipy’s constraint from *_ to >=0.14.0_, seaborn 0.9.1.rc0 upgrated Scipy’s constraint from >=0.14.0 to >=0.17.1, and seaborn 0.10.0rc0 upgrated Scipy’s constraint from >=0.17.1 to >=1.0.1**. As such, it is a warm warning of a potential dependency conflict issue for episcanpy.
Dependency tree
Thanks for your help. Best, Neolith