search

E3SM-Project / spack

A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
https://spack.io
Other
1 stars 2 forks source link

Need `albany` to depend on version of `trilinos-for-albany` other than `develop` #20

Closed xylar closed 1 year ago

xylar commented 1 year ago

@ikalash, one more probelm I'm running into. In albany/package.py there are bunches of lines like:

    depends_on("trilinos-for-albany@develop~superlu-dist+exodus+chaco~isorropia+tempus+teko~intrepid+intrepid2+minitensor+phalanx+pnetcdf+nox+piro+shards+stk+amesos2~amesos~hypre+ifpack2~mumps~suite-sparse+sandybridge~epetra~ifpack~ml+muelu~aztec+superlu+rol+frosch gotype=long_long", when="+sandybridge~epetra+optimization")

But the trilinos-for-albany@develop is is a problem for me, since I need these all to be trilinos-for-albany@comass-2023-08-03 when I'm using that tag of both Albany and Trilinos (on the E3SM-Project fork, see #19 ). Do you know of a way to handle this?

xylar commented 1 year ago

It seems like the solution just to have trilinos-for-albany without @develop and to have workflows that require trilinos-for-albany@develop to explicitly specify that.

bartgol commented 1 year ago

Does spack force to use the same git repo for all variants? I looked at the develop branch on e3sm-project fork, and it was 6 months old, while Trilinos updates develop pretty much daily...

We can add a github action (or a jenkins job, or whatever, though I am becoming a fan of gh actions), that updates our develop branch nightly. That way, we can change git property of trilinos spack pkg to point to the e3sm-project fork. However, if spack offered a way to use a different git repo for a particular variant, I would choose that path.

xylar commented 1 year ago

I believe that, yes, spack packages have to get their source from a single URL. I'll look into it because if not that would be simpler.

xylar commented 1 year ago

Yes, there's a url_for_version() function that we can use, so that does seem like an easy solution. I'll make a PR sometime soon.

bartgol commented 1 year ago

Ok. Meanwhile, I'm looking into github actions to sync our fork nightly. It is probably something we should do anyways (our fork should keep in sync with upstream), so it's worth doing it.

bartgol commented 1 year ago

Well, if that's not hard, we can do that. Otherwise, I think I found a way to sync our fork, so we can probably switch repo? What approach do you think is cleaner?