-
Notifications
You must be signed in to change notification settings - Fork 1k
Conversation
This method is a a complete and correct implementation for retrieving the list of direct dependency names. It should be able to be used by all dep commands, if needed.
Specifically, we need to switch map[string]bool for map[gps.ProjectRoot]bool. Trivial refactor, but it's preferable to do this anyway as this is a situation where gps.ProjectRoot should be used to denote that strings in this map are assumed to be project roots. Case in point, one of the importers was making the assumption that it had packages, not root paths, but it wasn't obvious without the type hinting.
Finally fixes golang#302.
cmd/dep/init.go
Outdated
@@ -137,12 +99,15 @@ func (cmd *initCommand) Run(ctx *dep.Ctx, args []string) error { | |||
if ctx.Verbose { | |||
ctx.Out.Println("Getting direct dependencies...") | |||
} | |||
pkgT, directDeps, err := getDirectDependencies(sm, p) | |||
|
|||
// If this errors, the next call will too; don't bother handling it twice. |
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 seems brittle.
Since GetDirectDependencyNames
calls ParseRootPackageTree
internally, what about an additional ptree
return from GetDirectDependencyNames
?
GetDirectDependencyNames(sm gps.SourceManager) (pkgtree.PackageTree, map[gps.ProjectRoot]bool, error) {
Edit: If this was the only reason for caching the result internally, then that could be simplified out too.
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.
Looks like that nil pointer is from the cache field too: if len(p.RootPackageTree.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.
i waffled over this a bit. it was between that signature, and what i did here - because we absolutely can't create a circumstance where casual use of the API results in hitting the disk twice for data that, at least in dep's model, hasn't changed.
however, i didn't particularly like having the extra return value - it felt like exposing a bit too much detail of the underlying behavior. the ptree
isn't what we asked for here. but, now that i've finished writing it and looking back, i'd agree that the cost is less than the complexity arising from adding this new statefulness dimension to *dep.Project
.
so yeah, i'll switch it around.
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.
actually looking at the code again, i've flipped back. not caching it internally also makes the FindIneffectualConstraints()
method much more complicated to implement.
there are a lot of different possible paths through this code, and orders in which different use cases might call it. we can't reasonably take out the caching. but i suppose that also adding the additional return value doesn't hurt - at minimum, it's one less instance of error handling (which was your original concern).
@@ -220,7 +220,10 @@ func (g *gopathScanner) scanGopathForDependencies() (projectData, error) { | |||
return projectData{}, nil | |||
} | |||
|
|||
for ip := range g.directDeps { | |||
for ippr := range g.directDeps { | |||
// TODO(sdboyer) these are not import paths by this point, they've |
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.
@carolynvs i noticed this while working on this. do you have any immediate thoughts about bugs we might have as a result of this pseudotype mismatch?
A convenience, as callers often need both the RootPackageTree and the direct dependencies map. Though this does further suggest that we ought to be able to stitch this up neatly in gps, at some point. Also, handle an error that was previously dropped.
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.
Tried it and works as expected.
This is how the warning looks:
Warning: the following project(s) have [[constraint]] stanzas in Gopkg.toml:
✗ golang.org/x/net
However, these projects are not direct dependencies of the current project:
they are not imported in any .go files, nor are they in the 'required' list in
Gopkg.toml. Dep only applies [[constraint]] rules to direct dependencies, so
these rules will have no effect.
Either or import/require packages from these projects to make them into direct
dependencies, or convert the [[constraint]] to an [[override]] to enforce rules
on these projects if they are transitive dependencies,
LGTM!
What does this do / why do we need it?
Warns the user when they have one or more
[[constraint]]
stanzas inGopkg.toml
, but do not have a direct dependency on what's named in there.There are also a few unrelated refactors in here, because it's just pointless to do those small things on their own.
What should your reviewer look out for in this PR?
i mean, i'm skipping tests - we can come back to those later, as long as hand-testing works. We need to ship the next release.
Do you need help or clarification on anything?
Error wording, especially. i was intentionally verbose here - i hope our errors will get more Elm-ish in this way going forward.
Which issue(s) does this PR fix?
#302