FAQ
I've worked with vendoring/package management in Go (and even tools to help
with it <https://github.com/Masterminds/glide>). I've worked with package
management in PHP <http://getcomposer.org/>, node.js <http://npmjs.org/>,
Python <https://pypi.python.org/pypi/pip/>, Ruby <http://rubygems.org/>,
and other languages. The Go community appears to be doing a number of
things differently than these other tools and communities (or at least in
the publicly talked about sense) and I'm wondering why. Let me explain.

In most of these other languages a typical workflow is to have a file
describing the dependencies and their versions. The versions are important
for reproducible builds. In each environment, whether it be development,
CI, or other places, the tooling reads this file and fetches the
dependencies (sometimes from a mirror). The dependencies are stored in a
vendor directory but it's not stored in your projects SCM.

This is a section from a PHP project in JSON as an example.

         "require": {
             "php": ">=5.3.2",
             "justinrainbow/json-schema": "~1.4",
             "seld/jsonlint": "~1.0",
             "symfony/console": "~2.5",
             "symfony/finder": "~2.2",
             "symfony/process": "~2.1",
             "seld/phar-utils": "~1.0",
             "seld/cli-prompt": "~1.0"
         },

Can someone explain why Go developers aren't looking to work in a similar
manner? Why vendoring in an SCM, not handling versions, and some other
habits are so prevalent?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Matt Silverlock at Jun 12, 2015 at 8:49 pm
    Part of the reason is that Go packages don't have the concept of a "version"—there's no manifest file with that information on Go projects to date.

    Further, not vendoring code means you always rely on the remote to be accessible, which doesn't help when you need to reproduce a build.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matt Farina at Jun 12, 2015 at 9:41 pm
    Some people want to vendor and others don't. I've heard arguments on both
    sides of that debate. The go tool shouldn't take a side in that debate.
    Even if Google is on one side of it.

    For having a reproducible build and dealing a remote repo you can have
    local mirrors. This is a common solution to this problem implemented all
    over the place.

    Since most of the major languages and platforms have a solution that deals
    with not vendoring the patterns you can use are mature. The alternative
    patterns to vendoring are wide spread.

    I'm simply suggesting the go tool not take a side and the discussions on
    patterns that don't involve vendoring show up more. You can continue to
    vendor while others use something else.
    On Friday, June 12, 2015 at 4:49:24 PM UTC-4, Matt Silverlock wrote:

    Part of the reason is that Go packages don't have the concept of a
    "version"—there's no manifest file with that information on Go projects to
    date.

    Further, not vendoring code means you always rely on the remote to be
    accessible, which doesn't help when you need to reproduce a build.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jun 12, 2015 at 11:00 pm

    On Fri, Jun 12, 2015 at 2:41 PM, Matt Farina wrote:
    I'm simply suggesting the go tool not take a side and the discussions on
    patterns that don't involve vendoring show up more. You can continue to
    vendor while others use something else.
    Just a note that for readers of golang-nuts that I tried to answer
    this over on golang-dev. Short version: I don't think the go tool is
    taking a side, except in the smallest possible way consistent with
    maintaining the Go ecosystem.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Paraiso Marc at Jun 13, 2015 at 2:58 am
    PHP didn't have a defacto official package manager 10 years ago.You used to
    download an entire framework and stick to it.

    Hope fully in 10 years, go will have one everybody agrees on.

    My problem with Go is that it comes with some "battery included" without
    fully taking advantage of them. Why can't I explicitely set branches I want
    to checkout when I "go get"? why can't I specify a branch in an import
    path? yet go get fetches some specific branches (go1) so it's possible ...

    Vendoring or not vendoring would irrelevant if I could write
    ..

    import "foo.org/package@0.1"

    or something like that.

      because package@0.1 and package0.2 would be 2 different packages.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 12, '15 at 8:26p
activeJun 13, '15 at 2:58a
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase