FAQ
Here's a proposal to remove the -copy=false behavior from godep save.

I'd like to gauge how people are currently using that mode and how
this change would affect the community.

https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M

I'm particularly interested in examples where using -copy=true is
measurably much worse than -copy=false. A few people have reported
pathological examples where a tiny project of a hundred lines imports
megabytes of dependencies. If this is common, we might have to rethink
the proposal. But there should be a high bar—the drawbacks of keeping
-copy=false are significant.

If this proposal seems reasonable, I'll amend it with a concrete
timeline, ask for more feedback, and set to implementing it.

--
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

  • Krzysztof Kowalczyk at Aug 1, 2014 at 3:30 am
    Please don't. I exclusively use -copy=false.

    I just did a quick test: my 5k loc (122kB of *.go code) blog engine
    (https://github.com/kjk/web-blog) would balloon in size by 1.2 MB.

    This is not exactly a tiny project and yet just a few dependencies
    (goamz, go-oauth, gorilla, go-metrics, blackfriday) are 10x the size
    of my own code.

    At work for convenience we have pretty big repo and part of that repo
    are utility functions. Right now I don't have to think about importing
    that repo just to get those functions but if I had to use -copy=true
    it would become untenable.

    Basically I don't want to think "will my dependencies become
    unreasonably large" every time I start a project.

    I don't think large repos are that rare because of tests. For example,
    blackfriday is just a markdown parser but the code + test is 444k
    because tests use majority of that.

    -- kjk

    On Thu, Jul 31, 2014 at 6:27 PM, Keith Rarick wrote:
    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.

    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M

    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.

    --
    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.
    --
    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.
  • Blake Mizerany at Aug 1, 2014 at 4:31 am
    “Basically I don't want to think "will my dependencies become

    unreasonably large" every time I start a project.”

    I think it is dangerous to sweep your dependencies under the rug.

    The amount of code being brought into your project using copy=true is a
    wonderful forcing function. Before I bring any dependency into a project, I
    habitually take a moment to look at the source and understand what I’m
    getting into. You don’t pick-up random items on the street and attempt to
    eat them - I hope - so why not follow that same rule with your dependencies?


    Maybe you could instead ask: "What code paths am I hitting in these
    dependencies? Are they pulling their weight? Can I just copy-and-paste a
    few lines attached to a proper comment for attribution? Is it its simpler
    to use basic control-flow instead?"


    -b

    On Thursday, July 31, 2014 8:30:51 PM UTC-7, Krzysztof Kowalczyk wrote:

    Please don't. I exclusively use -copy=false.

    I just did a quick test: my 5k loc (122kB of *.go code) blog engine
    (https://github.com/kjk/web-blog) would balloon in size by 1.2 MB.

    This is not exactly a tiny project and yet just a few dependencies
    (goamz, go-oauth, gorilla, go-metrics, blackfriday) are 10x the size
    of my own code.

    At work for convenience we have pretty big repo and part of that repo
    are utility functions. Right now I don't have to think about importing
    that repo just to get those functions but if I had to use -copy=true
    it would become untenable.

    Basically I don't want to think "will my dependencies become
    unreasonably large" every time I start a project.

    I don't think large repos are that rare because of tests. For example,
    blackfriday is just a markdown parser but the code + test is 444k
    because tests use majority of that.

    -- kjk


    On Thu, Jul 31, 2014 at 6:27 PM, Keith Rarick <k...@xph.us <javascript:>>
    wrote:
    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.

    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M
    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Krzysztof Kowalczyk at Aug 1, 2014 at 8:02 am
    I wrote that I don't want to count how many bytes my dependencies use,
    which is different from what you've (mis)read.
    On Thu, Jul 31, 2014 at 9:31 PM, wrote:
    “Basically I don't want to think "will my dependencies become

    unreasonably large" every time I start a project.”


    I think it is dangerous to sweep your dependencies under the rug.


    The amount of code being brought into your project using copy=true is a
    wonderful forcing function. Before I bring any dependency into a project, I
    habitually take a moment to look at the source and understand what I’m
    getting into. You don’t pick-up random items on the street and attempt to
    eat them - I hope - so why not follow that same rule with your dependencies?


    Maybe you could instead ask: "What code paths am I hitting in these
    dependencies? Are they pulling their weight? Can I just copy-and-paste a few
    lines attached to a proper comment for attribution? Is it its simpler to use
    basic control-flow instead?"


    -b


    On Thursday, July 31, 2014 8:30:51 PM UTC-7, Krzysztof Kowalczyk wrote:

    Please don't. I exclusively use -copy=false.

    I just did a quick test: my 5k loc (122kB of *.go code) blog engine
    (https://github.com/kjk/web-blog) would balloon in size by 1.2 MB.

    This is not exactly a tiny project and yet just a few dependencies
    (goamz, go-oauth, gorilla, go-metrics, blackfriday) are 10x the size
    of my own code.

    At work for convenience we have pretty big repo and part of that repo
    are utility functions. Right now I don't have to think about importing
    that repo just to get those functions but if I had to use -copy=true
    it would become untenable.

    Basically I don't want to think "will my dependencies become
    unreasonably large" every time I start a project.

    I don't think large repos are that rare because of tests. For example,
    blackfriday is just a markdown parser but the code + test is 444k
    because tests use majority of that.

    -- kjk

    On Thu, Jul 31, 2014 at 6:27 PM, Keith Rarick wrote:
    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.


    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M

    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
    --
    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.
  • Keith Rarick at Aug 1, 2014 at 5:02 am

    On Thu, Jul 31, 2014 at 8:30 PM, Krzysztof Kowalczyk wrote:
    I just did a quick test: my 5k loc (122kB of *.go code) blog engine
    (https://github.com/kjk/web-blog) would balloon in size by 1.2 MB.
    I'm not quite following this particular example. A fresh checkout
    of the repo at https://github.com/kjk/web-blog is 7.7MB on disk
    (not including .git) according to du. After running 'godep save ./...',
    the Godeps directory is 2.0MB according to du. That doesn't seem
    so bad. Even if this repo were of negligible size, 2MB just doesn't
    seem like much disk space as an absolute number.

    This feels analogous to the debate we had when git was becoming
    popular. Plenty of people argued it would be wasteful to have a full
    copy of project history on every computer. But disk space is cheap
    and getting cheaper fast, so it turns out to be no big deal.

    Like I mentioned above, the bar needs to be set pretty high to
    justify keeping -copy=false.

    --
    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.
  • Krzysztof Kowalczyk at Aug 1, 2014 at 7:59 am
    I only counted the code because the 7MB of html pages I wrote over
    past 10 years is neither here nor there.

    But fine, you can argue it's not the greatest example.

    My forum software https://github.com/kjk/fofou would go from ~0.3MB to
    ~0.7MB, more than doubling.

    My apptranslator https://github.com/kjk/apptranslator would go from
    ~0.6MB to ~1MB.

    Doubling the size of an average repo is pretty high in my book for the
    functionality provided.

    Care to quantify how big of a blowout is acceptable to you? 3x? 10x?

    I don't think git supports your thesis in any way.

    Git is very sophisticated in its storage scheme and a lot of effort
    went into storing the data in as few bytes as possible, to the point
    that a full git history is sometimes smaller than a regular svn
    checkout.

    Git developers are not cavalier about the bytes git consumes.

    -- kjk

    On Thu, Jul 31, 2014 at 10:01 PM, Keith Rarick wrote:
    On Thu, Jul 31, 2014 at 8:30 PM, Krzysztof Kowalczyk
    wrote:
    I just did a quick test: my 5k loc (122kB of *.go code) blog engine
    (https://github.com/kjk/web-blog) would balloon in size by 1.2 MB.
    I'm not quite following this particular example. A fresh checkout
    of the repo at https://github.com/kjk/web-blog is 7.7MB on disk
    (not including .git) according to du. After running 'godep save ./...',
    the Godeps directory is 2.0MB according to du. That doesn't seem
    so bad. Even if this repo were of negligible size, 2MB just doesn't
    seem like much disk space as an absolute number.

    This feels analogous to the debate we had when git was becoming
    popular. Plenty of people argued it would be wasteful to have a full
    copy of project history on every computer. But disk space is cheap
    and getting cheaper fast, so it turns out to be no big deal.

    Like I mentioned above, the bar needs to be set pretty high to
    justify keeping -copy=false.
    --
    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.
  • Peter Bourgon at Aug 1, 2014 at 8:16 am
    I'm not (yet) a heavy user of godep, but this change would dovetail
    nicely into my workflows, and I support it.
    Care to quantify how big of a blowout is acceptable to you? 3x? 10x?
    Vendoring dependencies necessarily carries a cost of more code in your
    repo. If you use a lot of dependencies, that cost is higher. This
    seems natural and easy to reason about. Structuring tools to optimize
    for that value seems penny-wise and pound-foolish. Bandwidth is cheap,
    especially at the scales we're talking about; 0.3MB = 0.7MB, for all
    practical purposes. Storage is dirt-cheap.

    I don't think git supports your thesis in any way.

    Git is very sophisticated in its storage scheme and a lot of effort
    went into storing the data in as few bytes as possible, to the point
    that a full git history is sometimes smaller than a regular svn
    checkout.

    Git developers are not cavalier about the bytes git consumes.

    -- kjk

    On Thu, Jul 31, 2014 at 10:01 PM, Keith Rarick wrote:
    On Thu, Jul 31, 2014 at 8:30 PM, Krzysztof Kowalczyk
    wrote:
    I just did a quick test: my 5k loc (122kB of *.go code) blog engine
    (https://github.com/kjk/web-blog) would balloon in size by 1.2 MB.
    I'm not quite following this particular example. A fresh checkout
    of the repo at https://github.com/kjk/web-blog is 7.7MB on disk
    (not including .git) according to du. After running 'godep save ./...',
    the Godeps directory is 2.0MB according to du. That doesn't seem
    so bad. Even if this repo were of negligible size, 2MB just doesn't
    seem like much disk space as an absolute number.

    This feels analogous to the debate we had when git was becoming
    popular. Plenty of people argued it would be wasteful to have a full
    copy of project history on every computer. But disk space is cheap
    and getting cheaper fast, so it turns out to be no big deal.

    Like I mentioned above, the bar needs to be set pretty high to
    justify keeping -copy=false.
    --
    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.
    --
    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.
  • Vitor De Mario at Aug 1, 2014 at 2:56 pm

    Bandwidth is cheap,
    especially at the scales we're talking about; 0.3MB = 0.7MB, for all
    practical purposes. Storage is dirt-cheap.
    I agree completely. Even though we're talking about "doubling" and
    "ballooning in size" if we consider the relative numbers, in absolute terms
    the highest number raised in this discussion so far is 2 MB, which includes
    html files, or 1.2 MB if we don't. These are not huge numbers by any
    measure.

    I am a heavy user of godep, using it everyday with the default behavior. I
    use it so much that I often try to "godep go build" on repos that don't use
    godep, by muscle memory. This proposal is all about making the tool
    simpler, deleting code and simplifying the docs. I'm 100% in favor of it.

    --
    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.
  • Jakob Borg at Aug 1, 2014 at 6:02 pm
    On 1 aug 2014, at 16:56, Vitor De Mario <vitordemario@gmail.com>
    I am a heavy user of godep, using it everyday with the default behavior. I use it so much that I often try to "godep go build" on repos that don't use godep, by muscle memory. This proposal is all about making the tool simpler, deleting code and simplifying the docs. I'm 100% in favor of it.
    Same situation here, same agreement. Carrying the cost of your dependencies is the cost of doing business, is usually negligible and when it isn't that's good to know too.

    //jb

    --
    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.
  • Dmitri Shuralyov at Aug 1, 2014 at 2:48 pm
    I also use --copy=false exclusively. In fact, as I wrote at
    https://news.ycombinator.com/item?id=7957775, I only use these 2 commands:

       rm ./Godeps && godep save --copy=false # Save current dep versions
       rm -rf $TMPDIR/godep && godep go build/test # build/test using saved dep versions


    However, I won't try to convince you to keep it; I think you should do what
    you feel is best. This proposal is not a surprise for me, as imo the
    current situation is far from optimal because godep lacks focus. It tries
    to support a lot of completely different workflows, and the documentation
    doesn't explain everything well enough (and known bugs remain unfixed for a
    long time).

    It's very easy to use once you understand how it works, but I don't think
    it's very accessible for beginners with the current amount of features and
    docs.

    If --copy=false ends up being removed, I'll likely keep using an older
    version or fork godep and simplify it to support only those 2 commands (and
    research other options, but I really like my existing workflow with the 2
    godep commands, it does everything I need).

    I don't think it makes sense to try to support both workflows (vendoring
    vs. Godeps file) in one tool, again, because of lack of focus.

    On Thursday, July 31, 2014 9:28:05 PM UTC-4, Keith Rarick wrote:

    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.


    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M

    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.
    --
    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.
  • Jonathan at Aug 1, 2014 at 11:08 pm

    On Thursday, July 31, 2014 6:28:05 PM UTC-7, Keith Rarick wrote:
    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.
    We use -copy=false for most packages in Flynn because we have dozens of
    distinct repos that import packages from each other and it doesn't make
    sense to have many copies of the same code saved in all of the repos.

    Jonathan


    --
    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.
  • Keith Rarick at Aug 1, 2014 at 11:29 pm

    On Fri, Aug 1, 2014 at 4:08 PM, wrote:
    it doesn't make
    sense to have many copies of the same code saved in all of the repos.
    Why doesn't it make sense? Many projects do this and it works nicely.

    If you use 'godep save -r', your commands will even be go-gettable.

    --
    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.
  • Jonathan Rudenberg at Aug 1, 2014 at 11:31 pm

    On Aug 1, 2014, at 4:29 PM, Keith Rarick wrote:
    On Fri, Aug 1, 2014 at 4:08 PM, wrote:
    it doesn't make
    sense to have many copies of the same code saved in all of the repos.
    Why doesn't it make sense? Many projects do this and it works nicely.

    If you use 'godep save -r', your commands will even be go-gettable.
    After I sent this message we decided to move most of these packages into a single repo for a variety of reasons, so I'm fine with dropping -copy=false now.

    Jonathan

    --
    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.
  • Camilo Aguilar at Aug 2, 2014 at 2:47 pm
    I'm also using -copy=false in several projects, so far I haven't fell the
    need for something different.
    On Thursday, July 31, 2014 9:28:05 PM UTC-4, Keith Rarick wrote:

    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.


    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M

    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.
    --
    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.
  • Kelsey Hightower at Aug 2, 2014 at 2:52 pm
    This seems reasonable to me. I've been happy with copying all my deps
    around and have never had an issue with file size.
    On Thursday, July 31, 2014 6:28:05 PM UTC-7, Keith Rarick wrote:

    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.


    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv_vPBMK1-9jBU4M

    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.
    --
    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 Reiferson at Aug 4, 2014 at 4:12 pm
    I can’t say that I’m excited that this is the direction we’re going in, but
    then again I can’t really come up with a great technical argument against
    it, so that’s probably telling.

    It certainly *isn’t* about disk space bloat.

    What I can say is that it just *feels* wrong that the only solution to
    handling dependencies is copying them into the repo. It feels like the
    less elegant solution of the two, despite its pros.

    Also, not a deal breaker, but one side effect of vendoring is that all of
    your other tooling needs to account for it (I need to ignore the vendored
    dir when I grep or use other command line tools or configure editors to
    ignore that path in search, etc.). Some things just don’t, like any of
    GitHub’s code metrics/graphs/etc. (understandably most are simply vanity
    metrics, but they’re impacted nonetheless).

    This is probably just me being cranky about having to do things differently
    though, so I’ll give it a spin and see how it works in practice.

    On Fri, Aug 1, 2014 at 7:12 PM, wrote:

    This seems reasonable to me. I've been happy with copying all my deps
    around and have never had an issue with file size.

    On Thursday, July 31, 2014 6:28:05 PM UTC-7, Keith Rarick wrote:

    Here's a proposal to remove the -copy=false behavior from godep save.

    I'd like to gauge how people are currently using that mode and how
    this change would affect the community.

    https://docs.google.com/document/d/1Dxo9PHfNVETus0UCAuviysZZAr2Hv
    _vPBMK1-9jBU4M

    I'm particularly interested in examples where using -copy=true is
    measurably much worse than -copy=false. A few people have reported
    pathological examples where a tiny project of a hundred lines imports
    megabytes of dependencies. If this is common, we might have to rethink
    the proposal. But there should be a high bar—the drawbacks of keeping
    -copy=false are significant.

    If this proposal seems reasonable, I'll amend it with a concrete
    timeline, ask for more feedback, and set to implementing it.
    --
    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.
    --
    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.
  • Keith Rarick at Aug 4, 2014 at 9:12 pm

    On Mon, Aug 4, 2014 at 9:12 AM, Matt Reiferson wrote:
    Also, not a deal breaker, but one side effect of vendoring is that all of
    your other tooling needs to account for it (I need to ignore the vendored
    dir when I grep or use other command line tools or configure editors to
    ignore that path in search, etc.).
    Yes, this is a little annoying, I agree. (My approach is not to configure
    anything specially, and just see all the vendored code show up in search
    results. But yeah, we still have to deal with it one way or another.)

    All I can say is that I've tried both ways, and the pleasure of working with
    vendored code far outweighs these small inconveniences, and everyone
    I can think of who I've talked to, who's seriously tried both, agrees.

    --
    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.
  • Robert Melton at Aug 4, 2014 at 9:23 pm

    On Mon, Aug 4, 2014 at 12:12 PM, Matt Reiferson wrote:
    What I can say is that it just feels wrong that the only solution to
    handling dependencies is copying them into the repo. It feels like the less
    elegant solution of the two, despite its pros.
    That seems like an argument against vendoring as a whole, more than a
    specific tool. If you absolutely need a dependable trustworthy build
    -- depending on the internet is a non-starter... everything has to
    live on your systems.

    I think this is a awesome direction for godeps, be great at one thing.
    Additionally, I think if you do want your dependencies to live on the
    internet, using gopkg.in makes a lot of sense... a lot of thought went
    into it.

    --
    Robert Melton | http://robertmelton.com

    --
    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.
  • Robfig at Aug 5, 2014 at 1:50 pm
    Coincidental:
    https://groups.google.com/d/msg/golang-nuts/dc0hIrbWX_U/llL-PsY5TIsJ
    On Monday, August 4, 2014 5:24:13 PM UTC-4, Robert Melton wrote:

    On Mon, Aug 4, 2014 at 12:12 PM, Matt Reiferson <sna...@gmail.com
    <javascript:>> wrote:
    What I can say is that it just feels wrong that the only solution to
    handling dependencies is copying them into the repo. It feels like the less
    elegant solution of the two, despite its pros.
    That seems like an argument against vendoring as a whole, more than a
    specific tool. If you absolutely need a dependable trustworthy build
    -- depending on the internet is a non-starter... everything has to
    live on your systems.

    I think this is a awesome direction for godeps, be great at one thing.
    Additionally, I think if you do want your dependencies to live on the
    internet, using gopkg.in makes a lot of sense... a lot of thought went
    into it.

    --
    Robert Melton | http://robertmelton.com
    --
    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
postedAug 1, '14 at 1:27a
activeAug 5, '14 at 1:50p
posts19
users13
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase