I was using godeps before and now govendor, and never felt 100% happy with either one. I have some feedback of how I think the package management tool should work from the developer perspective, and here some features that I think is crucial.
1. Standardize the package file. With govendor, this is vendor/vendor.json. This is great, but I want to commit vendor/vendor.json to repo, but not the vendor folder. I had to do some `git add -f`, a bit yucky. Just standardize it, something like dep.json, or perhaps Depfile. Doesn't matter the filename, just standardize it, and please don't put it under the vendor folder. 2. I want to specify which branch or which tag or which sha revision of my dependencies. Do not let this process to be automatic unless a version is not specified in which case it should be the latest dep can acquire. It is frustrating when it pulls the wrong one. 3. I want to update my vendor folder, and it should use the Depfile as the authoritative source of what versions should be downloaded. Not the $GOPATH! Package management tool should move away from relying $GOPATH/src as its authoritative source. My $GOPATH/src contains versions of code that could be in development, months old, and what not. Let me control my $GOPATH with `go get`, while dep can use other ways to pull code directly to the vendor folder without messing with the $GOPATH. $GOPATH is the development workspace. vendor folder should have the stable versions for that particular project. I had a time when govendor pulled a version from my GOPATH. Ugh. 4. Packages/libraries should be allowed to have its own Depfile. I have heard/read somewhere that somehow this is discouraged by the Go community. I am not sure why. I thought it would simplify the process by a whole lot from development perspective that you reuse other people code. Put the responsibility to the library maintainers to maintain up-to-date Depfile. And from dependency management, you don't have to scan the entire source files to find the dependency tree. In case of version conflict, such as package A depends on C.v1, and package B depends on C.v2, just pick one (latest) version but WARNS the user. If there is a compile error, it won't build anyway. I feel like the only way to resolve this is to actually overwrite the import statements. 5. Since packages is allowed to have its own Depfile, then each project should only be concerned with its direct dependencies, not the complete tree. 6. Let Depfile be user specified, not something that dep automatically generates. I kinda like the way Gemfile and Gemfile.lock works. Gemfile is user specified, while Gemfile.lock is automatically generated and contains the complete dependency tree. You commit Depfile to repo, but you do not commit Depfile.lock to repo. Having said that, I normally approach problems from end-user perspective and start there. Assuming `dep` is the command here, the following commands are possibly some that I would use: `dep init` - Read Depfile, checks out direct dependencies to vendor folder, figure out the entire tree, create Depfile.lock, and fill the vendor folder with the complete dependency tree, while also stripping out unnecessary files like tests, .gitignores, etc from them. `dep update %package_name%` - Updates Depfile.lock for that particular package only to use the latest version (and of course its dependencies), iff the package is specified on Depfile with an unspecified version. If not specified on Depfile, just throw the error. `dep build` - Build the project using the vendor folder ONLY. This is to make sure that your app can be shipped to somewhere else with a different environment. I can totally see somebody has github.com/foo somewhere in their GOPATH, but not specified on Depfile, and just says 'it works on my computer?' And...that's it. I don't understand why all the dependency tools have these dozens of commands that 99% of time you don't end up using. I would rather have tools that is plain but consistent and has expected behaviors, than attempt to be smart but failed. Something nice: Allow zipping up the packages in the vendor folder so I can actually check the zips into the repo. While this can be counterintuitive, but recently I have had a problem where I had to do a complete pull of my old project, and one of the dependencies had breaking changes. I did not want to update my code to follow the breaking changes, and the package maintainer is bad at keeping track of branches and tags that there is virtually no way for me to go back in time and find the version that is compatible. To make matters worst, this library depends on 6 other libraries that all depend on each other, and all have breaking changes. Yes, NP-complete problem. I ended up writing my own. This also would be nice for deploys. If you can check in your entire dependency, instead of redownloading all code from github or wherever, in case of situations where internet connection isn't available. I hope I don't sound too demanding. I like Go, but the reason why I haven't committed to it is frustration working with the dependency tools, something that other languages seem to have no problem with. And other tools like godeps and govendor seem to manage to create their own problems. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
