Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set dependencies conditions to specific defined versions #152

Open
atteggiani opened this issue Oct 14, 2024 · 0 comments · May be fixed by #153
Open

Set dependencies conditions to specific defined versions #152

atteggiani opened this issue Oct 14, 2024 · 0 comments · May be fixed by #153

Comments

@atteggiani
Copy link

Description of the problem

Currently, the conditions for the dependencies of the mom5 package are defined in a way that does not explicitly mention a defined version:

with when("@:access-esm0,access-esm2:"):

This, according to Spack version comparison documentation, would include the defined version master. However, at a first glance, it is not too obvious and is prone to errors.

Proposed solution

I suggest setting the dependencies based on specific defined versions, for clarity and simplicity.

In this specific case, the dependencies could be set as:

- with when("@:access-esm0,access-esm2:"):
+ with when("@master"):   
    depends_on("[email protected]:")
    depends_on("[email protected]:")
    # Depend on virtual package "mpi".
    depends_on("mpi")
    depends_on("datetime-fortran")
    depends_on("oasis3-mct+deterministic", when="+deterministic")
    depends_on("oasis3-mct~deterministic", when="~deterministic")
    depends_on("libaccessom2+deterministic", when="+deterministic")
    depends_on("libaccessom2~deterministic", when="~deterministic")
with when("@access-esm1.5:access-esm1.6"):
    depends_on("[email protected]:4.7.4")
    depends_on("[email protected]:4.5.2")
    # Depend on "openmpi".
    depends_on("[email protected]:4.1.0")
    depends_on("[email protected]")

access-esm1.5 and access-esm1.6 versions could be further separated if different dependencies are required.

This would likely not add any overhead when new versions need to be added, because the package.py file would still need to be changed and the dependencies of the new version checked. In that case, a further condition can be added for the new version (or the new version can be included in an already-present condition).

This would improve the package clarity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant