You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The `EnvSpec` type has become overloaded and used is contexts where it
can represent things that don't make sense. For example, `"-"` is a
legal (empty) `EnvSpec` which can be used to create an empty
environment, but it doesn't make sense to `spfs push` an empty
environment.
A `RefSpec` is a similar type but instead of representing items that can
be used to create an environment, it represents items that can be copied
between repositories.
The `EnvSpec` scope has narrowed to restrict that any digests within it
are treated as object digests (not payloads), because it is non-sensical
to create an environment from a payload digest.
The `RefSpec` allows digests to be payload digests, but does not support
live layer files. It is also required to be non-empty, since it doesn't
make sense to copy "nothing" between repositories. Spec files are still
supported although the files themselves cannot be copied, however it
should be possible to provide the list of refs to sync to `spfs push`
via a spec file.
# Design Notes
There are still several places that accept an `EnvSpec` that is intended
to be used to create an environment, but it is first used to sync items
locally, so it needs to be converted to a `RefSpec` first (and the sync
result converted back to an `EnvSpec`). These conversions are either
lossy or fallible, so there are things likely broken in this PR that
just aren't covered by tests yet.
In this design, it makes sense for the conversion from `EnvSpec` to
`RefSpec` to be lossy (instead of fallible) in the context of syncing content
locally.
These changes were created to build on the ideas in PR #1289 and further
leverage `PartialDigestType` introduced there.
Signed-off-by: J Robert Ray <[email protected]>
0 commit comments