The dependency management tool is made public

[Peter Bourgon]

We've now made the https://github.com/golang/dep repo public. Please
take a look and give it a once-over. Note that this is very much a
pre-alpha release, made public to help iron out bugs and guide its
evolution. There will be breaking changes to come, so please don't
e.g. commit the manifest or lock files to your important repos just
yet :)

Any questions, feel free to ask me! And thank you all for your
continued interest and patience!

Cheers,
Peter.

[mario.l....@gmail.com]

On Tuesday, January 24, 2017 at 8:34:48 AM UTC-8, Peter Bourgon wrote:

> ...

This looks like the start of something good. Having a community blessed package manager is sorely needed.

One thing that I like about yarn package manager is using explicit subcommands instead of overloading. Yarn makes it clear when you `install`, it means install dependencies from the lock file. To add dependencies, the subcommand is `add some_dep`. To upgrade dependencies the subcommand is `upgrade` or `upgrade some_dep@to_new_version`. I found it much simpler than npm which overloaded `install` to install, add, upgrade. It seems dep is overloading `ensure` from the examples in the README.

[Pavan Kumar Sunkara]

I agree with Mario. I have a repo with a single main.go file for which I wanted to use this tool. I know it’s still early, but I expected `dep init` to do something like what `npm init`. But, what it did was writing a lock file and an empty manifest file which looks weird. I would really love to hash out the subcommands of this tool and make them more explicit and intuitive.

Thanks

-- 
Pavan Kumar Sunkara

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Boyer]

By all means, post some issues! We can discuss there why we didn't design the subcommand set in the way you're describing. Things could still change, of course - the tool is experimental - but I/we're hoping that the choices we've made will ultimately allow for at least as an intuitive experience as npm or yarn - one that's specifically aligned with Go's particular characteristics.

On Tuesday, January 24, 2017 at 2:39:04 PM UTC-5, Pavan Kumar Sunkara wrote:

I agree with Mario. I have a repo with a single main.go file for which I wanted to use this tool. I know it’s still early, but I expected `dep init` to do something like what `npm init`. But, what it did was writing a lock file and an empty manifest file which looks weird. I would really love to hash out the subcommands of this tool and make them more explicit and intuitive.

Thanks

-- 
Pavan Kumar Sunkara

On 25 January 2017 at 1:02:20 AM, mario.l....@gmail.com (mario.l....@gmail.com) wrote:

On Tuesday, January 24, 2017 at 8:34:48 AM UTC-8, Peter Bourgon wrote:

> ...

This looks like the start of something good. Having a community blessed package manager is sorely needed.

One thing that I like about yarn package manager is using explicit subcommands instead of overloading. Yarn makes it clear when you `install`, it means install dependencies from the lock file. To add dependencies, the subcommand is `add some_dep`. To upgrade dependencies the subcommand is `upgrade` or `upgrade some_dep@to_new_version`. I found it much simpler than npm which overloaded `install` to install, add, upgrade. It seems dep is overloading `ensure` from the examples in the README.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[dan.s...@gmail.com]

Using Glide now but this is a big step for the Go community. Go sorely needs "npm" and "package.json". Npm is one of the few things I really like about working with .js

[junkma...@gmail.com]

Why not generated the manifest and lock files inside the vendor folder? Would be less clutter.

vendor/
lock.json
manifest.json

[Dave Cheney]

Is there precedent in another language for doing this? I know that
some Go developers feel strongly about not having these turds in the
root for their project, yet are silent on things like Makefiles,
Dockerfiles, travis.ymls, and so on.

> --
> You received this message because you are subscribed to the Google Groups "Go Package Management" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.

[Sam Boyer]

Placing these files (turds?) inside vendor/ would concretely bind us to vendor/ in the long term. We prefer to treat the use of vendor/ as an implementation detail.

On Tuesday, January 24, 2017 at 11:30:46 PM UTC-5, Dave Cheney wrote:

Is there precedent in another language for doing this? I know that
some Go developers feel strongly about not having these turds in the
root for their project, yet are silent on things like Makefiles,
Dockerfiles, travis.ymls, and so on.

On Wed, Jan 25, 2017 at 2:51 PM,  <junkma...@gmail.com> wrote:
> Why not generated the manifest and lock files inside the vendor folder? Would be less clutter.
>
> vendor/
>   lock.json
>   manifest.json
>
> --
> You received this message because you are subscribed to the Google Groups "Go Package Management" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[gopher....@gmail.com]

I fail to see how Makefiles, Dockerfiles, travis.ymls are the same as lock.json and manifest.json. The key difference is that the former are entirely optional and different per project requirements while the latter will be used in every Go project.

[junkma...@gmail.com]

I don't see a problem with coupling it to the vendor directory since that's the primary use case 99.99% of the time anyway. Perhaps you could provide a flag to specify a different directory if needed?

[Andrew Gerrand]

There are arguments to put it in the project root, and arguments to put it somewhere else.

What's important is that they're in the same place in every project.

Andrew

On 25 January 2017 at 17:38, <junkma...@gmail.com> wrote:

I don't see a problem with coupling it to the vendor directory since that's the primary use case 99.99% of the time anyway. Perhaps you could provide a flag to specify a different directory if needed?

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

To post to this group, send email to go-package-management@googlegroups.com.

[Bradley Falzon]

Although I'm on the fence about this:

- dep could, in theory, look for those files in vendor/ first, then fall back to a root directory. There is precedent for programs looking for config files in different locations. 

- I've seen before, but can't find a reference to, people using config/ for their dotfiles, config/golang.org/ is a possible option

I like the appeal of namespacing lockfile.json or manifest.json, it's simply too likely to clash with other dependency management tools that the user could be using (npm/yarn for example) if dep stored those files with generic names in the root folder.

On 25 January 2017 at 17:08, <junkma...@gmail.com> wrote:

I don't see a problem with coupling it to the vendor directory since that's the primary use case 99.99% of the time anyway. Perhaps you could provide a flag to specify a different directory if needed?

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

To post to this group, send email to go-package-management@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Bradley Falzon
br...@teambrad.net

[oss...@gmail.com]

Another consideration is typical scm usage, say git. If dep metafiles default
to ./vendor, it necessitates added lines in each .gitignore file so as to exclude ./vendor, yet still include ./vendor/<metafile> .... Conceptually, project basedir filepaths have a tight hierarchic claim to scm, subdir filepaths less so.

I'm sympathetic to the namespace counter-argument. But I think their user base will fade in time, and/or start defaulting to ./vendor themselves?!

[Bradley Falzon]

On the namespacing points, I just meant we should reconsider calling the files lock and manifest if they're stored in the root, as many repositories have multiple languages in them, not necessarily arguing for folders or global namespace, just something more Go specific.

--

You received this message because you are subscribed to the Google Groups "Go Package Management" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.

To post to this group, send email to go-package...@googlegroups.com.

[Henrik Johansson]

If there is a desire to not commit the vendor folder then I think the files belong outside of it.

Having multiple possible locations seems bad. Linux distros usually look for stuff everywhere which is a pain imho.

[Pavan Kumar Sunkara]

Yes, I think there is a big desire to ignore the vendor folder. I like to think of the files like this:

vendor => node_modules

lock.json => npm-shrinkwrap.json

manifest.json => package.json

People using the npm generally add the node_modules directory to gitignore. In my honest opinion, this is a good convention and dep should follow that.

Thanks.

-- 
Pavan Kumar Sunkara

[Henrik Johansson]

I kind of like to check in the vendor folder. It gives offline capability and speed that is hard to  beat.

Keeping the files out of vendor allows for both approaches to  be used so that makes sense.

[Eric Johnson]

I'm in favor of leaving them at the root of a project, and giving them names unique to the Go ecosystem. That will make Go projects readily discoverable:

* unique file name will be clues to various tools that there are specific classes of files in these directories: backup logic would know to skip backing up the executable in this folder. Code scanning/analysis programs will be able to auto-discover more. IDEs could scan for these files to find projects. Humans can scan zip files for these files to identify all the projects found in a zip archive.

* burying the file in a sub-directory diminishes its symbolic importance. Knowing how pernicious bit-rot is, the files are essential to understanding the source code.

I'm all in favor of unique-to-Go names at the root of the project.

Eric

[junkma...@gmail.com]

But every package in vendor has its own directory. manifest.json and lock.json would be the only two files without a directory at the root of vendor. So it would still just be one line ./vendor/*/

On Wednesday, 25 January 2017 01:55:41 UTC-5, Andrew Gerrand wrote:
> There are arguments to put it in the project root, and arguments to put it somewhere else.
> What's important is that they're in the same place in every project.
>
>
> Andrew

I agree. I'm not endorsing the idea of being able to choose different directories. I just threw it out there because that's the only reason I can see for not concretely binding to vendor.

[Bradley Falzon]

For the record, I've raised https://github.com/golang/dep/issues/168 to finalise discussion on locations and filenames.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.
To post to this group, send email to go-package-management@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Bradley Falzon
br...@teambrad.net