-
Notifications
You must be signed in to change notification settings - Fork 225
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
[plugins] Use reflikes for plugins #1845
Conversation
This reverts commit b7eec16.
2d41210
to
8aaec6b
Compare
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.
Generally lgtm, but I was having trouble following some of the logic (see comments inline)
nix/flake/flakeref.go
Outdated
if allowSlashesIfRef { | ||
split = strings.SplitN(upath, "/", 3) |
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.
I don't understand what scenario is being dealt with here. What does allowSlashesifRef
do, and why does it only care about 3 slashes, while the else
can deal with an unlimited number of slashes?
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.
I think this is to fix a bug where we weren't parsing github refs with slashes in them correctly. I broke out the flakeref fixes into a separate PR just so they can be tracked separately - #1863.
nix/flake/flakeref.go
Outdated
@@ -206,7 +206,7 @@ func parseGitHubRef(refURL *url.URL, parsed *Ref) error { | |||
// github:<owner>/<repo>(/<rev-or-ref>)?(\?<params>)? | |||
|
|||
parsed.Type = TypeGitHub | |||
split, err := splitPathOrOpaque(refURL) | |||
split, err := splitPathOrOpaque(refURL, true) |
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.
nit: comment bool param
nix/flake/flakeref.go
Outdated
@@ -129,7 +129,7 @@ func parseURLRef(ref string) (parsed Ref, fragment string, err error) { | |||
// [flake:]<flake-id>(/<rev-or-ref>(/rev)?)? | |||
|
|||
parsed.Type = TypeIndirect | |||
split, err := splitPathOrOpaque(refURL) | |||
split, err := splitPathOrOpaque(refURL, false) |
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.
nit: comment bool param
) | ||
|
||
// RefLike is like a flake ref, but in some ways more general. It can be used | ||
// to reference other types of files, e.g. devbox.json. |
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.
is the only difference that flake ref refer to directories, whereas here it can refer to a specific file? If so, could we call that out more strongly?
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.
flake refs are specific to nix flakes and I wanted to avoid modifying that. The only real difference here is that there's an optional default filename the reflike refers to. In the case of plugins is devbox.json
but I want to leave the door open to using reflikes for composing multiple projects as well if that is something we want to support in the future (In that case the filename is probably a devbox.json
)
internal/plugin/github.go
Outdated
"https://raw.githubusercontent.com/", | ||
p.Owner, | ||
p.Repo, | ||
lo.Ternary(p.Rev == "", "master", p.Rev), |
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.
to use golang std lib: cmp.Or(p.Rev, "master")
internal/plugin/github.go
Outdated
p.Owner, | ||
p.Repo, | ||
lo.Ternary(p.Rev == "", "master", p.Rev), | ||
p.withFilename(p.Dir), |
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.
not sure I follow: why are we passing in p.Dir
(a directory) as an argument for withFilename
?
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.
different plugin types have different fields represent the path. Local plugins use Path
while github plugins use Dir
Maybe a cleaner solution could be to implement a configPath()
function for each type. (though they would still both have some duplicate code)
internal/plugin/github.go
Outdated
repo string | ||
revision string | ||
dir string | ||
RefLike |
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.
instead of embedding the struct, could we make it an explicit field to distinguish methods/fields that are from RefLike versus native to githubPlugin
?
But its tolerable if it means having to re-implement a lot of methods unnecessarily
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.
I can make that change. It does mean that plugin.Repo
becomes plugin.ref.Repo
so the code is a big uglier. (There's roughly 12 callsites in this file that would change)
internal/plugin/github.go
Outdated
p.dir, | ||
p.Owner, | ||
p.Repo, | ||
lo.Ternary(p.Rev == "", "master", p.Rev), |
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.
consider: cmp.Or
Thanks for catching the flakeref parsing bugs. Still reviewing this PR, but I broke them out into a separate PR and added a couple tests - https://github.com/jetpack-io/devbox/pull/1863/files. |
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.
I'm having some trouble following the ref-like syntax. It sounds like it allows specifying specific files, but I'm not sure where it's parsing that (or maybe we're not yet?).
That's actually a bug fixed in #1850. Will fix here as well. |
Actually this is fine here. |
Cleanup PR #1867 (The stacked nature makes it a bit tricky to make those changes here) |
Summary
This changes plugins to use new
reflike
struct. It brings it more in line with how flake refs work. For now, only some types are supported.How was it tested?
CICD