Skip to content

Telcon: 2021 11 03

Jump to bottom Edit New page
Peter Scheibel edited this page Nov 3, 2021 · 26 revisions

This is the next planned meeting.

We are skipping meeting on Wed. October 27th to prepare for the upcoming 0.17.0 release.

Attendees

  • Peter Scheibel
  • Mark Krentel
  • Massimiliano Culpo
  • Tammy Dahlgren
  • Phil Sakievich
  • Richarda Butler
  • Andy Gallo
  • Gregory Becker
  • Andy Gallo
  • Asher Mancinelli
  • Cameron Rutherford
  • Erik Schnetter

Agenda

We will start with a discussion on spack develop/environments

See:

  • https://github.com/spack/spack/discussions/24966

    • https://github.com/spack/spack/pull/22087
      • Allow developing the same package multiple times in an environment (differentiated by spec)
      • Changes the schema for envs (so existing envs with dev specs would be broken - could we add alternative parsing options)

  • https://github.com/spack/spack/issues/26295#issuecomment-931277758

    • Cannot specify develop for specs that are dependencies of a root spec if they are not mentioned in the spec list

  • https://github.com/spack/spack/pull/25981

  • Phil: with 24966, it appears you can combine develop specs with stacks

  • Greg: if you want to build different variants of a package, and each with the same spack develop branch, then this is supported now

    • The issue then is related to developing different versions of a spec
      • Or having a develop and non-develop version

  • Greg: 24966 potentially adds complexity to the semantics of when develop specs are used

    • For now you name the package, and any time that package appears as a root or dep in the env, then all specs in the env use that source
    • With 24966, you only use develop if you match by spec
      • It may be unclear to users when this is happening
    • We could require versions on all specs specified as develop
      • And if you don't specify a version with spack develop, we choose the default one automatically and place it in the spack.yaml
    • If you update the new schema with an "allow-repeat-specs" flag, then you can get the old semantics
spack:
  specs: [sirius]
  develop:
  allow-repeat-specs: false
  - spec: spfft # or spfft@1.0.4
    path: path/to/sources
  • Phil: Use cases based on onboarding users with spack develop
    • In one case there was a package with a version called develop that pulled from master
      • hypre is an example
    • Also encountered issue where Spack wasn't cloning everything
    • Greg: ideally if we provide a branch/repo to spack develop, these are recorded along with the path
      • This is more info than --no-clone requires, but would help users share envs with one another
      • These properties can be stored in the spack.yaml (don't need to be stored in the spec yaml)

Agenda items for later

  • Harmen (not sure if I can join): there are packages like libblastrampoline / libmpitrampoline which provide a blas / lapack / mpi interface to link to, and forwards calls to an actual blas / lapack / mpi provider lib. E.g. julia uses it to link to a blas interface for its binary deps, allowing the user to switch blas provider at runtime, avoiding abi issues. The problem is Spack only allows one provider per dag, but these packages both provides the virtual and depends on the virtual. How do we deal with this "composition" type of pattern? I was thinking: maybe we can relax unique provider per dag to unique provider per subgraph connected through link type deps? Then libblastrampoline can provide blas, and depend on blas as a run-type dependency.

  • Peter: Can we get rid of csh support

    • I always run bash first thing when I start a shell on Mac OS
    • Does anywhere require CSH support and have no option for bash support?
Add a custom footer
Clone this wiki locally