Skip to content

[geant4] Restore single point of maintenance for versions#37381

Closed
greenc-FNAL wants to merge 4 commits intospack:developfrom
greenc-FNAL:feature/geant4-geant4-data
Closed

[geant4] Restore single point of maintenance for versions#37381
greenc-FNAL wants to merge 4 commits intospack:developfrom
greenc-FNAL:feature/geant4-geant4-data

Conversation

@greenc-FNAL
Copy link
Copy Markdown
Member

  • Enable package-specific dependency directives
  • [geant4] Restore single point of maintenance for versions

@greenc-FNAL
Copy link
Copy Markdown
Member Author

Closes #37380.

@greenc-FNAL greenc-FNAL changed the title feature/geant4 geant4 data [geant4] Restore single point of maintenance for versions May 2, 2023
Use `directives.pkg_depends_on()` to create a directive to handle dependency on the corresponding version of `geant4-data`.
@greenc-FNAL greenc-FNAL force-pushed the feature/geant4-geant4-data branch from a631dc0 to d7f21e4 Compare May 2, 2023 14:08
@spackbot-app spackbot-app bot added the tests General test capability(ies) label May 2, 2023
@drbenmorgan
Copy link
Copy Markdown
Member

@greenc-FNAL, I guess this should be marked as Draft until #37380 is merged? It seems to have similar/same commits.

@greenc-FNAL greenc-FNAL marked this pull request as draft May 2, 2023 14:56
@greenc-FNAL
Copy link
Copy Markdown
Member Author

Will also need #37383 to pass audit tests.

@adamjstewart
Copy link
Copy Markdown
Member

Can we just make a new directive like this for all packages? Dozens of packages need this feature, not just this one.

@greenc-FNAL
Copy link
Copy Markdown
Member Author

greenc-FNAL commented May 2, 2023

Can we just make a new directive like this for all packages? Dozens of packages need this feature, not just this one.

Of course. I'm not sure of the best way to make the directive simple to use and flexible enough for the general case, though. Something like this, maybe? Unfortunately, I have no idea what an implementation of _merge() would look like.

def _merge(dep_spec, spec_bit):
  """Here, a miracle occurs."""
  pass

@directive(("dependencies"))
def depends_on_matching_version(spec):
    """Package-specific directive to depend on the corresponding version of a given spec"""

    def _execute_depends_on_matching_version(pkg):
        dep_spec = Spec(spec)
        for vers in pkg.versions.keys():
            this_dep_spec = _merge(dep_spec, f"@{vers}")
            pkg_depends_on(pkg, this_dep_spec, when=f"@{vers}", type="run")

    return _execute_depends_on_matching_version

@adamjstewart
Copy link
Copy Markdown
Member

There was an initial attempt in #14002 but that PR was abandoned. Basically the only thing I would change is to wrap this into the existing depends_on directive instead of creating a new directive. We'll need a flag to control the number of digits since some packages require the same X.Y.* while others require exactly X.Y.Z.

@greenc-FNAL
Copy link
Copy Markdown
Member Author

I'm fine with wrapping this into the OG depends_on(), but I'm still not seeing how to implement _merge(): depends_on() accepts spec which may include variants, flags, or even (not particularly sensible, but still) a version. I need a way to merge an anonymous spec (just the version) with the given named spec in an unambiguous way, and a first sweep of spec.py wasn't enough to illuminate one for me. Any pointers gratefully accepted.

@greenc-FNAL
Copy link
Copy Markdown
Member Author

greenc-FNAL commented May 3, 2023

We'll need a flag to control the number of digits since some packages require the same X.Y.* while others require exactly X.Y.Z.

I'm fine with the pkg_to_dep_version function parameter from #14002 since one can easily send Version or lambda ver: ver.up_to(2).

@greenc-FNAL
Copy link
Copy Markdown
Member Author

@adamjstewart I think I have an implementation: testing now.

@greenc-FNAL
Copy link
Copy Markdown
Member Author

See #37418.

@github-actions
Copy link
Copy Markdown
Contributor

This pull request has been automatically marked as stale because it has not had
any activity in the last 6 months. It will be closed if there is no further activity.
Thank you for your contributions!

@github-actions github-actions bot added the stale label Jul 11, 2025
@github-actions
Copy link
Copy Markdown
Contributor

This pull request was closed because it had no activity for 30 days after being marked stale.

@github-actions github-actions bot closed this Aug 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core PR affects Spack core functionality directives stale tests General test capability(ies) update-package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants