-
Notifications
You must be signed in to change notification settings - Fork 249
[lockfile] add lockfile.Tidy and call from ensurePackagesAreInstalled #1109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
internal/lock/lockfile.go
Outdated
@@ -127,6 +128,10 @@ func IsLegacyPackage(pkg string) bool { | |||
!strings.HasPrefix(pkg, "/") | |||
} | |||
|
|||
func (l *File) Tidy(project devboxProject) { | |||
l.PackageMap = lo.PickByKeys(l.PackageMap, project.Packages()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikeland86 not 100% confident that the keys in the lockfile are intended to match the package-names in devbox.json. Can you confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah they should always match. Right now nix.Input
uses Input.String()
instead of Input.Raw
as a key (raw is the package name in devbox.json) but they always match for devbox packages. I think we should probably change those callsites to use input.Raw
just to be sure (since for flakes Raw
and String()
might not be the same)
But for this use case this is safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I see. We should probably change that sooner than later...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, pending revert of Packages
name change. You can also remove the Packages()
function
internal/lock/lockfile.go
Outdated
func (l *File) Tidy(project devboxProject) { | ||
l.PackageMap = lo.PickByKeys(l.PackageMap, project.Packages()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't need a parameter. The lockFile struct has access to devbox struct (i.e. l.devboxProject.Packages()
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh good point
internal/lock/lockfile.go
Outdated
@@ -127,6 +128,10 @@ func IsLegacyPackage(pkg string) bool { | |||
!strings.HasPrefix(pkg, "/") | |||
} | |||
|
|||
func (l *File) Tidy(project devboxProject) { | |||
l.PackageMap = lo.PickByKeys(l.PackageMap, project.Packages()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah they should always match. Right now nix.Input
uses Input.String()
instead of Input.Raw
as a key (raw is the package name in devbox.json) but they always match for devbox packages. I think we should probably change those callsites to use input.Raw
just to be sure (since for flakes Raw
and String()
might not be the same)
But for this use case this is safe.
internal/lock/lockfile.go
Outdated
@@ -22,7 +23,7 @@ type File struct { | |||
resolver | |||
|
|||
LockFileVersion string `json:"lockfile_version"` | |||
Packages map[string]*Package `json:"packages"` | |||
PackageMap map[string]*Package `json:"packages"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to rename this. See this draft #1113
You can access conflicting functions on structs by specifying the embedded struct explicitly (e.g. lock.devboxProject.Packages())
That said, when embedded structs get this complicated it's probably better to get rid of them (and just make them explicit fields) (not something that needs to happen in this PR though).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that draft was useful, thanks!
That said, when embedded structs get this complicated it's probably better to get rid of them (and just make them explicit fields) (not something that needs to happen in this PR though).
yeah, that's what savil/update-lockfile-v1
was about. But I thought it may receive pushback so took this more conservative approach. See #1120
Summary
Problem:
if I change devbox.json from [email protected] to [email protected], and do devbox install, I still see the [email protected] in the devbox.lock (in addition to the new [email protected])
This PR ensures that when we update installed packages, we also update the lockfile
to have the set of packages that match those of the devbox.json config.
implementation note: I needed to rename lockfile.Packages to a different name
since devboxProject is embedded in the lockfile.File struct and we have a name
conflict.
Fixes #1095
How was it tested?