Closed hongyi-zhao closed 5 months ago
Hey @hongyi-zhao,
To be honest, I'm still educating myself about best practices when it comes to setting dependencies. As I understand it, if one expects their package to be used as a library (expecting it to be installed in an already mature environment), then the dependencies should be as abstract as possible, with lower and/or upper bounds as you suggested.
This package, however, is meant to be standalone, which is why I also generated the monstrosity of a requirements.txt you see using pip-tools
. I will update the README soon with a note about the best reproducible way to install this package, which is simply git clone
followed by pip install -r requirements.txt
, in a fresh environment. To be fair, I'm still playing around with things, and whenever I create a new environment to install, I just pip install -e .
after I clone the repo, which usually grabs the most recent versions of the dependencies in pyproject.toml
. I should, at some point, define some bounds for the dependencies in file, though.
If you have any other questions, please don't hesitate.
My core philosophy is:
>=
for specifying dependencies, pip
will choose the latest available version that meets or exceeds the specified version.
- If your project depends on many packages, how can you ensure that you're using the latest and most stable features of these packages? If you use
>=
for specifying dependencies,pip
will choose the latest available version that meets or exceeds the specified version.
That would be quite risky, as some of the dependencies (pymatgen being one) sometimes introduce breaking changes. I still follow changelogs and if I see a change important enough to bump up dependency versions, I will do so. Other than that, I'm content with knowing that the package works as intended with the packages specified in requirements.txt
.
- If there are better alternatives available among these dependencies, efforts should be made to ensure compatibility with these implementations. For example, can your package work compatibly with atomate2?
This is something I've considered and decided against in the interest of time and other work because I only ran into atomate2 well into the development cycle. At some point, I will spend some time with atomate2 to gauge how much effort it would be to convert.
I guess I addressed your questions/concerns and can close this now.
Regarding the numerous dependencies required by this package, I have the following questions:
==
is used instead of>=
to select versions. Why?Regards, Zhao