You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Standard Python dependency management practice ([1][2][3]) would look as follows:
setup.py (or setup.cfg / pyproject.toml) for capturing only direct dependencies, with loosest applicable constraints
this ensures interoperability, i.e. package can operate smoothly alongside others (which have their own dependencies and lifecycle), while mitigating risk of dependency hell
requirements*.txt for exhaustively capturing both direct and transitive dependencies, pinned to specific versions
this ensures reproducibility, i.e. we can recreate the same environment for our package
Current setup
The approach currently followed by fuse seems to be a bit of a "mix-up":
setup.py does not directly define any dependencies, but rather sources various requirements*.txt files
requirements*.txt files contain various dependencies, but with mixed/unclear semantics:
scope: I understand they do not contain (all) transitive dependencies => can lead to reproducibility issues
constraints: mostly unconstrained but some times constrained or even pinned to specific versions => can lead to interoperability issues / "dependency hell"
Proposal
In order to improve interoperability and reproducibility, while also providing clearer semantics for library usage and maintenance, it would be best to align to the dependency management scheme outlined above.
Standard dependency management practice
Standard Python dependency management practice ([1][2][3]) would look as follows:
setup.py
(orsetup.cfg
/pyproject.toml
) for capturing only direct dependencies, with loosest applicable constraintsrequirements*.txt
for exhaustively capturing both direct and transitive dependencies, pinned to specific versionsCurrent setup
The approach currently followed by fuse seems to be a bit of a "mix-up":
setup.py
does not directly define any dependencies, but rather sources variousrequirements*.txt
filesrequirements*.txt
files contain various dependencies, but with mixed/unclear semantics:Proposal
In order to improve interoperability and reproducibility, while also providing clearer semantics for library usage and maintenance, it would be best to align to the dependency management scheme outlined above.
[1] https://packaging.python.org/en/latest/discussions/install-requires-vs-requirements/#install-requires-vs-requirements-files
[2] https://pip.pypa.io/en/stable/topics/dependency-resolution/#possible-solutions
[3] https://pip.pypa.io/en/stable/topics/repeatable-installs/
The text was updated successfully, but these errors were encountered: