golang / dep Goto Github PK

View Code? Open in Web Editor NEW

12.9K 256.0 1.1K 12.21 MB

Go dependency management tool experiment (deprecated)

Home Page: https://golang.github.io/dep/

License: BSD 3-Clause "New" or "Revised" License

Go 98.50% Shell 0.79% JavaScript 0.49% CSS 0.17% Makefile 0.06%

golang dependency-manager package-manager toolchain

dep's Introduction

Dep

dep is a dependency management tool for Go. It requires Go 1.9 or newer to compile.

NOTE: Dep was an official experiment to implement a package manager for Go. As of 2020, Dep is deprecated and archived in favor of Go modules, which have had official support since Go 1.11. For more details, see https://golang.org/ref/mod.

For guides and reference materials about dep, see the documentation.

Installation

You should use an officially released version. Release binaries are available on the releases page.

On MacOS you can install or upgrade to the latest released version with Homebrew:

$ brew install dep
$ brew upgrade dep

On Debian platforms you can install or upgrade to the latest version with apt-get:

$ sudo apt-get install go-dep

On Windows, you can download a tarball from go.equinox.io.

On other platforms you can use the install.sh script:

$ curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh

It will install into your $GOPATH/bin directory by default or any other directory you specify using the INSTALL_DIRECTORY environment variable.

If your platform is not supported, you'll need to build it manually or let the team know and we'll consider adding your platform to the release builds.

If you're interested in getting the source code, or hacking on dep, you can install via go get:

go get -u github.com/golang/dep/cmd/dep

dep's People

Contributors

Stargazers

Watchers

Forkers

jessfraz sdboyer mattn gangleri tanuck krisnova rakyll christopherbiscardi fuji-151a keijiyoshida imjerrybao rangk lakevilladom zchee tabboud alindeman rathneesh iporsut ranahasan msingle vuckovicdejan vanadium23 erizocosmico kujtimiihoxha rajrockzz amezghal haya14busa xmattstrongx hloeffler tro3 mem rhymond typeless groob wrapperclass schmaluk scottrigby jrs43215 zhangf911 junneyang carolynvs linearregression dictav brianstarke zbintliff darioalessandro takyoshi steve-winter domgreen jlaswell ziffusion paddymahoney jcchavezs campoy clebs lclarkmichalek tomwilkie rubythonode gonuuts marcin-dudek chrrrles cutedogspark dutchcoders spenczar ruflin mccjul sebastianviera akarokr jackychiu winghim khorinis91 codesword ewanvalentine lparth akarl nowk addly lfany matrixy rkive darkowlzz briansorahan chrishines barkinet rowhit ibrasho-forks myles-mcdonnell-daemon felipeweb ascandella ahmetb zknill marwan-at-work b-boogaard nathanielc dxfeng10 sttts wslulciuc nmiyake mikijov dlespiau

dep's Issues

Panic `TestInit()` windows

see sdboyer/gps#146

related: #96

happening on solve when packages are nested in root project:

Build started
git config --global core.autocrlf input
git clone -q [email protected]:golang/hoard.git c:\gopath\src\github.com\golang\hoard
Warning: Permanently added the RSA host key for IP address '192.30.253.113' to the list of known hosts.
git fetch -q origin +refs/pull/96/merge:
git checkout -qf FETCH_HEAD
Running Install scripts
rmdir c:\go /s /q
appveyor DownloadFile https://storage.googleapis.com/golang/go%GOVERSION%.windows-amd64.msi
Downloading go1.7.windows-amd64.msi (74,977,280 bytes)...100%
msiexec /i go%GOVERSION%.windows-amd64.msi /q
set Path=c:\go\bin;c:\gopath\bin;%Path%
go version
go version go1.7 windows/amd64
go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=c:\gopath
set GORACE=
set GOROOT=C:\go
set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
go build
go test
--- FAIL: TestInit (3.50s)
	hoard_test.go:262: git [checkout v0.8.0] standard error:
	hoard_test.go:263: Note: checking out 'v0.8.0'.
		
		You are in 'detached HEAD' state. You can look around, make experimental
		changes and commit them, and you can discard any commits you make in this
		state without impacting any branches by performing another checkout.
		
		If you want to create a new branch to retain commits you create, you may
		do so (now or later) by using -b with the checkout command again. Example:
		
		  git checkout -b <new-branch-name>
		
		HEAD is now at 645ef00... doc tweaks
		
	hoard_test.go:262: git [checkout 42b84f9ec624953ecbf81a94feccb3f5935c5edf] standard error:
	hoard_test.go:263: Note: checking out '42b84f9ec624953ecbf81a94feccb3f5935c5edf'.
		
		You are in 'detached HEAD' state. You can look around, make experimental
		changes and commit them, and you can discard any commits you make in this
		state without impacting any branches by performing another checkout.
		
		If you want to create a new branch to retain commits you create, you may
		do so (now or later) by using -b with the checkout command again. Example:
		
		  git checkout -b <new-branch-name>
		
		HEAD is now at 42b84f9... Merge pull request #384 from mnzt/master
		
	hoard_test.go:167: running testhoard [init]
	hoard_test.go:187: standard error:
	hoard_test.go:188: hoard: Finding dependencies for "github.com/golang/notexist"...
		hoard: Found 3 dependencies.
		hoard: Building dependency graph...
		hoard: no buildable Go source files in C:\Users\appveyor\AppData\Local\Temp\1\gotest447160834\src\github.com\golang\notexist
		hoard: Package "github.com/golang/notexist/foo", analyzing...
		hoard: Package "github.com/golang/notexist/foo" has import "github.com/Sirupsen/logrus", analyzing...
		hoard: Package "github.com/golang/notexist/foo" has import "github.com/pkg/errors", analyzing...
		hoard: Package "github.com/golang/notexist/foo/bar", analyzing...
		hoard: Analyzing transitive imports...
		hoard: Analyzing "github.com/pkg/errors"...
		hoard: Analyzing "github.com/Sirupsen/logrus"...
		hoard: Analyzing "golang.org/x/sys/unix"...
		hoard: Solving...
		Root project is "github.com/golang/notexist"
		 2 transitively valid internal packages
		 3 external packages imported from 3 projects
		✓ select (root)
		| ? revisit github.com/golang/notexist to add 1 pkgs
		panic: should never call ListPackages on root project
		
		goroutine 1 [running]:
		panic(0x787fc0, 0xc0421adde0)
			C:/go/src/runtime/panic.go:500 +0x1af
		github.com/golang/hoard/vendor/github.com/sdboyer/gps.(*bridge).ListPackages(0xc042422ff0, 0xc04240bae0, 0x1a, 0x0, 0x0, 0x9b9460, 0xc0421adc10, 0x30, 0x12, 0x0, ...)
			c:/gopath/src/github.com/golang/hoard/vendor/github.com/sdboyer/gps/bridge.go:283 +0x22d
		github.com/golang/hoard/vendor/github.com/sdboyer/gps.(*solver).checkRequiredPackagesExist(0xc0424245a0, 0xc04240bae0, 0x1a, 0x0, 0x0, 0x9b9460, 0xc0421adc10, 0xc0421add30, 0x1, 0x1, ...)
			c:/gopath/src/github.com/golang/hoard/vendor/github.com/sdboyer/gps/satisfy.go:111 +0xa7
		github.com/golang/hoard/vendor/github.com/sdboyer/gps.(*solver).check(0xc0424245a0, 0xc04240bae0, 0x1a, 0x0, 0x0, 0x9b9460, 0xc0421adc10, 0xc0421add30, 0x1, 0x1, ...)
			c:/gopath/src/github.com/golang/hoard/vendor/github.com/sdboyer/gps/satisfy.go:28 +0x149
		github.com/golang/hoard/vendor/github.com/sdboyer/gps.(*solver).solve(0xc0424245a0, 0x0, 0x0, 0x1)
			c:/gopath/src/github.com/golang/hoard/vendor/github.com/sdboyer/gps/solver.go:427 +0x2d9
		github.com/golang/hoard/vendor/github.com/sdboyer/gps.(*solver).Solve(0xc0424245a0, 0x55, 0xc042129cc0, 0x1a, 0xc042156840)
			c:/gopath/src/github.com/golang/hoard/vendor/github.com/sdboyer/gps/solver.go:330 +0x95
		main.(*initCommand).Run(0x9f2570, 0xc042037d90, 0x0, 0x0, 0x0, 0x0)
			c:/gopath/src/github.com/golang/hoard/init.go:151 +0x1025
		main.main()
			c:/gopath/src/github.com/golang/hoard/main.go:95 +0x652
		
	hoard_test.go:197: go [init] failed unexpectedly: exit status 2
	hoard_test.go:84: remove C:\Users\appveyor\AppData\Local\Temp\1\gotest447160834\src\github.com\golang\notexist: The process cannot access the file because it is being used by another process.
FAIL
exit status 1
FAIL	github.com/golang/hoard	27.523s
Command exited with code 1

Feedback: dep status headers should be CAPITALIZED

Really simple one, instead of

Project  Constraint  Version  Revision  Latest  Pkgs  Used

it should be

PROJECT  CONSTRAINT  VERSION  REVISION  LATEST  PKGS  USED

in the grand tradition. If there's consensus I'm happy to do this.

Write a README

because READMEs

dep -v causes a panic

I'm going to fix this I'm just reminding myself in case I get distracted in the next ten minutes.

$ ./dep -v
panic: runtime error: slice bounds out of range

goroutine 1 [running]:
main.main()
	/usr/local/google/home/jessfraz/.go/src/github.com/golang/dep/main.go:63 +0x347

Feedback: make sure terminal output doesn't exceed some width

This is based on my first run with the tool. Some commands can dump output that stretches arbitrarily wide across the terminal. Even though I had fullscreen on a 27" monitor with a small font, it was wrapping. Not good. We should ensure that doesn't happen, either by having some kind of max-width formatting terminal output writer (tricky; would involve word wrap logic, etc.) — or by being more careful in how output is generated, making sure each line has a limited amount of information. I prefer the second option. Thoughts?

we need a CLA bot

I will look at how to set this up internally

gps doesn't handle directories with multiple packages

A common idiom for packages with generated code is to include a file named something like gen.go that contains

package main

// +build ignore

...

These are then invoked with go generate. When doing a gps.ListPackages, the analysis of that package will fail with a *build.MultiplePackageError.

We need to be able to handle this. Should build ignore be handled specially?

ensure: without args, should create+populate the vendor folder

Have repo without manifest, lock, or vendor folder
dep init
dep ensure

What I expected: the vendor folder populated with the deps listed in the lock file.

What happened instead: the repo was solved, but no vendor folder was created.

ci: test if people update vendor

This is what a lot of projects would need as well and we should test it on our project as well:

use ci to test if changes to vendor appropriately update the manifest and lock & vice versa

Introduce a transactional, "safe group writer"

There are three basic things that dep writes to disk:

Manifest
Lock
Dep source code (i.e. vendor)

One component of correct operation of the tool is keeping these three states in sync. Or, at minimum, not letting them go out of sync unintentionally. That basically entails taking a transaction-style approach to state changes:

If writing one of the states to disk, the existing state should be preserved until the last possible moment, and rolled back to if any error occurs
If writing multiple states to disk, it is safe to assume that correctness of the overall operation is predicated on all the writes succeeding. So, we need to be expand the transaction to cover all the write ops - if one fails, they all fail, and all pre-existing disk states are restored.

This isn't a super-simple thing to do, so I might say we could defer a bit while we work on higher-priority areas. However, I already implemented this for glide, and the use pattern for us is mostly the same. So, I can do some slapdash work to adapt that for our purposes here.

Having a contained API for this would reduce some cognitive load when implementing commands anyway, which is useful - there's already plenty to think about with what's going on there.

ensure: add --override

Make the help text not suck

Help text is currently fairly awful, as it was really just copied out from the spec doc. It needs to be made proper before we open up.

depcache usability concerns

These are just some things I noticed, they should probably be folded into a larger ticket to refactor the depcache.

Default directory $HOME/depcache is no good; you probably want $HOME/.config/dep/cache
Ctrl-C during an init (for example) leaves a stale sm.lock; that should be cleaned up

Replace isStdLib() stub

In #18, we introduced an isStdLib() stub method and hardcoded what we needed into it. This is something that gps really should be addressing, though, so I opened sdboyer/gps#113. Once that's done, we can scrap our stub and rely on gps.

Names

dep works for now. But do we want to stick with it?

This is, of course, the bikesheddiest of bikesheds. I'm planting it here early so we can let it percolate in the background, rather than trying to go at it full tilt later.

CONTRIBUTING.md says use Gerrit

The CONTRIBUTING.md says we use Gerrit, but we clearly don't.

We should either update that file prior to opening up, or actually switch to Gerrit.

Feedback: dep ensure must not fail catastrophically if operations time out

This is feedback from my first run with the tool. It happens very often that github.com will start timing out https operations if I make a bunch of them in a row. And dep ensure makes a bunch of them in a row. When the timeouts start happening, it basically corrupts and kills the entire ensure run, which could invalidate many seconds/minutes worth of work, which is very frustrating.

Just throwing some ideas out: can ensure have some concept of partial, resumable progress, so that if it fails I can pick it up again from that point, rather than having to start from scratch? Failing that, can it make some attempt to throttle and retry failed network operations?

TestInit depends on golang.org/x/sys not moving

The expected lock contains the hash of the tip of master, 478fcf54317e52ab69f40bb4c7a1520288d7f7ea. Or rather, what WAS the tip of master, until 10 hours ago.

We either need to rely on something else that we can guarantee won't move, or look up the current tip of golang.org/x/sys in the test and use that in the lock.

ensure: handle if dep is unused?

I kinda like the behavior now but we should decide on it.

if you run dep ensure now with a dep you are not currently using it will add it to the manifest but not the lock.

After you've added your code using the dep, you can rerun dep ensure and it will be in the lock as well.

I personally like this because i like to checkout packages locally before starting coding for goimports and code completion but we should decide if this is the behavior everyone wants.

Issue writeups

To facilitate contributions, and minimize frustration and duplication, we should do writeups of major known/planned issues, and make judicious application of the "help wanted" label.

There are a bunch of functions with ProjectRoot

...But they all have different purposes and kind of have a different definition of "project root"

ensure: custom logger for solve

something pretty with maybe levels

dep: Lock comparison check issues

locksAreEquivalent compares the two Memo fields of the locks, but AFAICT both new and old locks that we pass in have the same memo, when they should have been different (in the case of an ensure -update on dep itself ATM). I suspect gps is creating a memo for the existing lock file, not the new one because a new vendor is not as of yet written out.

Start handling gps solve failures

#18 introduces our first gps solve run, which means it's also our first exposure to solve failures. There's a whole menagerie of possibilities there. It's a big enough problem that I've barely even put up issues about it - just sdboyer/gps#20.

I've not invested a ton of time really making errors great in gps so far primarily because it's just hard to do so without a) other people and b) a real tool. glide has provided some of the latter, but less of the former. This is a large problem, though, and making errors comprehensible to users is something we should expect to invest a lot of time in - in this domain, it's one of the main dividing lines between a great and horrible tool.

We've gotta start somewhere, though, so I'm opening this ticket.

converting k8s and testing

Here is how I'm testing it, right now k8s uses godep so I did this:

# restore all the deps to my workspace
$ godep restore

# remove the old crap
$ rm -rf Godeps
$ rm -rf vendor

# run init
$ nest init

now we wait

Move to the format we actually intend for the manifest and lock

I think there's general agreement among us four that JSON is not what we want to use. I know that @freeformz and I both lean TOML. But we're gonna have to do this, and probably sooner rather than later.

Unfortunately, there's a wrinkle: one of the major arguments for using YAML or TOML over JSON is that both of those formats support comments, and JSON does not. However, neither BurntSushi/toml nor go-yaml/yaml appear to support encoding comments. idk about other implementations, but...well, that really sucks. (This knowledge courtesy of the cockroachdb folks, reporting it about glide: Masterminds/glide#691)

I don't know where that leaves us, but the clock is ticking.

big projects have a tendency to be rate limited by github

unsure how to fix this....

add rm

TODOs before we open up

Just opening a meta-issue where we can drop in things that we need to do before opening this up to the public. Everyone please feel free to edit

Write a README
Clear guidelines for use - e.g., "please don't commit code using this yet, manifest format may still change."
Guidelines for giving feedback
Write up issues for major areas that we feel others could reasonably jump in and help with (plus with a "Help Wanted" label on them)
"production-grade" help text
eliminate obvious panics - right now, the particular thing would be ensure without a version specifier

Implement "update" behavior

There's no way, at present, for users to update deps within existing constraints, at all. That includes both updating all deps, and updating just specific individual deps. The spec doc includes this functionality under ensure, and has this to say:

For updating all deps at once:

Flags:
	-update		update all packages

For updating just targeted deps:

Fetch/update github.com/heroku/rollrus to latest version, including transitive dependencies (ensuring it matches the constraints of rollrus, or—if not contrained—their latest versions):
	$ dep ensure github.com/heroku/rollrus

I actually asked @peterbourgon to basically cut these out of the improved helptext in #78 because we don't support them right now.

Now, -update is pretty easy. (I might actually just whip up a PR tonight that does it). But I feel a little hesitant about the second one, because now that we're actually writing this, it strikes me as counterintuitive. Having the constraint changes the manifest, but not having it induces an update (assuming it's already in the manifest?). And, if you ensure github.com/foo/bar and it's already present in the project, you get update behavior, but if it's not present, then...what? We've got two identical inputs from the user taken on significantly different intent depending on current state. That feels like we're heading into icky UX territory.

Ofc, maybe that's fine, at this early stage - we can try something, get feedback, then trying something else.

Sort information in lock and manifest before output

There are three basic approaches to dealing with output order of information in config files like our manifest and lock, I think:

Just sort it, all, always
Ignore order, and let the maps we use internally wreak havoc on diffs
Try to split the difference by sometimes sorting and sometimes trying to preserve user input

2 is just obviously a non-starter. 1 can be frustrating; people don't necessarily like it when tools seem to 'arbitrarily' rewrite their config files, even if it's to put the keys in alpha order. But 3, the approach that indulges that, is so much harder than 1, I think.

So, seems to me like we need to start with 1, and maybe maybe at some indeterminate future time think about 3?

I'm opening this as its own issue because the sort logic is already sitting implemented in another PR (#13) that's not been merged yet, but I want to use it in another PR I'm working on now. Plus, this is a design choice, and so maybe bears some discussion.

docs: write usage guidelines

Write up some clear guidelines for initial use - e.g., "please don't commit code using this yet, manifest format may still change."

Feedback: make help output consistent and pithy

This is based on my first run with the tool. Here is what I propose...

Refactor dep -h, dep help slightly
Make dep init -h work the same as dep help init
Refactor and shorten dep help init significantly
Implement dep status -h to work the same as dep help status
Refactor and shorten dep help status significantly
Refactor and shorten dep help ensure significantly
Move more sophisticated ensure usage examples to another help flag
Implement dep rm -h to work the same as dep help rm
Refactor and shorten dep help rm

If everyone is happy with the "what", I'll make a PR with my version of these changes, and we can debate the "how".

CI

I'll be working on this for going public and supporting multi-arch

Linux (Travis) #92
OSX #96
Windows #95, #103, #104
ARM?

Handle failures better in txn writer

Right now, the "safe" writer pretty much just drops errors made when attempting to rollback on the floor, but keeps on trying anyway. Quoting @freeformz in #60:

Discussed a bit with @sdboyer yesterday and while I think there are usable bits here, I think it may be a little too defensive. For instance, most errors that will happen during file operations will be IO/file errors and once you hit one of those, it's likely that later ones on the same device(s) / filesystem(s) will also fail. So I prefer the write to temp and fail early bits if possible.

This definitely makes a lot of sense. One possible avenue for improvement in the current implementation would be to look for errors on rollback attempts, and if we encounter some, stop further rollback attempts and just dump a bunch of info to the user about what disk state we think we're exiting in.

Does that seem like an improvement? Maybe there's a better way to go?

Implement "init"

In stages:

write an empty manifest
analyze deps, and write them to manifest

tests: better coverage across the board

add integration tests ensuring all the behavior we have outlined in the design spec
better unit test coverage

Adding the good-first-pr label, because test could be added for any function, big or small, we also have a framework for integration testing where you could easily copy paste another test and change some things to test something else.

Here is an example of an integration test: https://github.com/golang/dep/blob/master/remove_test.go#L9

If you want to write a test, just write here what you wish to test so no one takes the same one :)

ensure: handle when no version is passed

right now it will either error or fall through to god knows what, so we should handle it as the default branch which might not be master

Replace versionInWorkspace() stub

In #18, we introduced a versionInWorkspace() stub function that is supposed to inspect a GOPATH workspace and determine the version of a provided project root. Right now, we've just hardcoded versions for the dep tool's own external deps, but this needs to be actually addressed.

@freeformz said he might be able to take a stab at this, so I'm assigning him.

always prune unused packages

This is a question from my first run with the tool. I imported package A, which lives in repo R. Repo R also contains package B, which I don't use. Should/could dep prune B?

tests: stop wiping memo

Gotta do it sooner or later, preferably sooner

Feedback: init and status should provide some user feedback

This is based on my first run with the tool. I propose that dep init and dep status should give some kind of immediate feedback to the user, to indicate they're going out to the network and the operation may take a little time. At the moment I don't have much confidence in what's going on.

What do we think? Should this be hidden behind a -v flag?

tests: repos we can eventually test on

These are some of my small ones we can try before attacking something like k8s ;)
they all currently use gvt

ensure: don't panic when no version spec is provided

ensure panics right now if the user doesn't provide a version specifier, e.g.:

$ dep ensure github.com/foo/bar

panic currently occurs in manifest.go:155

Implement "ensure"

not much to say here rn but it's happening already in #34

Question: does ensure need to reach out to the network as much as it does?

This is feedback based on my first run with the tool. I was surprised that ensure seemed to always re/query each dep's source of truth, and re/solve the entire graph, even if I was just updating a single dep. It led to significant frustration due to mismatched expectations. Is this necessary? Can it be improved with e.g. a local cache?

Feedback: dep ensure output creeps to the right

This is based on my first run with the tool. Running dep ensure would make this funny tree/waterfall thing in ASCII.

 6 transitively valid internal packages
 8 external packages imported from 6 projects
✓ select (root)
| ? attempt github.com/go-kit/kit with 2 pkgs; at least 1 versions to try
| | try github.com/go-kit/kit@master
| ✓ select github.com/go-kit/kit@master w/2 pkgs
| | ? attempt github.com/go-logfmt/logfmt with 1 pkgs; at least 1 versions to try
| | | try github.com/go-logfmt/logfmt@master
| | ✓ select github.com/go-logfmt/logfmt@master w/1 pkgs
| | | ? attempt github.com/kr/logfmt with 1 pkgs; at least 1 versions to try
| | | | try github.com/kr/logfmt@master
| | | ✓ select github.com/kr/logfmt@master w/1 pkgs
| | | | ? attempt github.com/go-stack/stack with 1 pkgs; at least 1 versions to try
| | | | | try github.com/go-stack/stack@master
| | | | ✓ select github.com/go-stack/stack@master w/1 pkgs
| | | | | ? attempt github.com/prometheus/client_golang with 2 pkgs; at least 1 versions to try
| | | | | | try github.com/prometheus/client_golang@master
| | | | | ✓ select github.com/prometheus/client_golang@master w/2 pkgs
| | | | | | ? attempt github.com/beorn7/perks with 1 pkgs; at least 1 versions to try
| | | | | | | try github.com/beorn7/perks@master
| | | | | | ✓ select github.com/beorn7/perks@master w/1 pkgs
| | | | | | | ? attempt github.com/oklog/ulid with 1 pkgs; 3 versions to try
| | | | | | | | try github.com/oklog/[email protected]
| | | | | | | ✓ select github.com/oklog/[email protected] w/1 pkgs
| | | | | | | | ? attempt github.com/golang/protobuf with 1 pkgs; at least 1 versions to try
| | | | | | | | | try github.com/golang/protobuf@master
| | | | | | | | ✓ select github.com/golang/protobuf@master w/1 pkgs
| | | | | | | | | ? attempt github.com/pkg/errors with 1 pkgs; at least 1 versions to try
| | | | | | | | | | try github.com/pkg/errors@master                                                                                                                                                                              | | | | | | | | | ✓ select github.com/pkg/errors@master w/1 pkgs
| | | | | | | | | | ? attempt github.com/pborman/uuid with 1 pkgs; at least 1 versions to try
| | | | | | | | | | | try github.com/pborman/uuid@master

I guess it shouldn't do that.

Implement the analyzer's DeriveManifestAndLock()

To start actually dealing properly with transitive deps, we have to implement our analyzer's DeriveManifestAndLock method. Should be quite simple, at least for now - we check for our manifest and optionally a lock (if we want to use preferred versions), in the provided directory, load them up if found, and return them.

docs: write feedback guidelines

Maybe it's a CONTRIBUTING.md, or maybe it's something else, but we should outline what kind of feedback we're looking for, and how we're looking to get it, before we open up.

status on freshly cloned repo does nothing

running status without first running ensure on this repo, freshly cloned returns nothing