I guess I'm confused. There are three things at the core of Spack:

Package classes, which contain metadata and constraints for resolving dependencies and package configuration.
Spec instances, which represent package configurations, i.e. the dependency DAG.
Package instances, which are basically installers for concrete Specs.

Specs are dynamic; Packages do two things: the class has the static constraints (invariants) and the instance is the installer. They're conflated like that b/c this has been shown (in Homebrew, at least) to make for a nice package DSL. I tend to think that's true.

There are currently some issues with the lifecycles of those things. What I see as the problems are:

Package.__init__() does some setup that should really be in the metaclass (i.e. associated with the class, not the instance). I'd have to review the code but I think this is entirely vestigial -- maybe it was expedient when I first wrote the class, but now it's hacky and in the way.
As a result of (1), most of Spack, when it really needs the package class, calls Repo.get() with just the name of the package, to get an instance of Package that it uses only for metadata. This stuff should be getting the class by name instead.
Repo currently caches package instances by Spec, and those Package instances have a Spec. This is unnecessary and causes confusion. I think I thought that we'd need to cache instances after loading package classes, but really just caching the classes is fine.

I think the lifecycle should look like this:

User (or something else) provides an abstract Spec.
Concretize the spec.
Get the class for the root, and use that to construct a Package instance for just this install.
Install using the package instance. While this is happening, the Package has a self.spec (since the methods in Package need to look at the Spec).
After that, the package forgets about the Spec until someone calls install on it again.

RE: #5600 Extensions: The Package.extends() method should really be on Spec, since whether or not something "extends" something else depends on how it was installed. i.e., some packages only extend Python when build with an optional variant. In general, if it is a dynamic thing, it belongs in Spec. I think we added extends() before there were optional dependencies, and it's remained somewhat awkward since.

Does that help?

Fix package has-a spec relationship #5996

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions