dep silently fails if no .go files are present

Created on 14 Feb 2017  路  9Comments  路  Source: golang/dep

In an empty dir in an empty GOPATH, I ran dep ensure, and it made a lock and a manifest file, but did not actually download any dependencies. I added a .go file and it started behaving as expected.

help wanted good first issue error-handling

Most helpful comment

I would like to tackle this! :)

All 9 comments

Yeah, it's probably worth adding a check to make sure there's at least one valid dir/pkg of go files, and error out if not.

Having it work anyway would be fine by me, too ;)

Maybe Im doing sthg wrong. But I dont see that dep downloads anything to the vendor-folder at all although there is sthg in the manifest. Can you please explain the meaning of lock.json? Thanks

@lavalamp i think probably better to error, as demonstrated by @mlukasch's confusion here.

@mlukasch unlike tools in other languages, dependencies are only required if they actually appear in the import graph (or if they appear in the requires section of the manifest). The dependencies section in the manifest merely specifies constraints on projects IF they are required.

This should be a pretty straightforward fix, if anyone wants to tackle it :)

I would like to tackle this! :)

@mylk13 awesome! 馃帀馃帀

The most important direction I can give here is that you'll be looking for the results of a call to gps.ListPackages() - a gps.PackageTree. If the PackageTree.Packages map is empty, then it means no packages were found.

Of course, the map also might have some elements, but gps.PackageOrErr is basically an enum, so if all of the members just have errs, then it's basically equivalent to having no packages. Probably. You can start poking and get a feel for how it works, then we can discuss in the PR the best handling for these cases.

Not sure if too late to add some input to this, but one use case I know of to download deps even in an empty directory is when using Docker's layer caching mechanism to cache the RUN dep ensure layer for subsequent image builds. In the Node.js world, it's pretty common to COPY the package.json, RUN npm install, and then copy in source code to the image. I was trying to do something similar with the .lock and .toml files, but ran into this issue.

@perryao mm...interesting use case. I think we could probably shoehorn it in under the dep ensure -vendor-only behavior described in the new WIP spec, though i'll admit that it starts to stretch the meaning. Even with that new flag, you'd still have to copy the .toml AND the .lock, because we don't allow dep to run at all unless there's a manifest in place.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michael-go picture michael-go  路  3Comments

mohanraj-r picture mohanraj-r  路  3Comments

abeMedia picture abeMedia  路  3Comments

jiharal picture jiharal  路  3Comments

tapir picture tapir  路  3Comments