how to update dependencies.tsv

[Eric Snow]

On Fri, Oct 31, 2014 at 2:11 AM, roger peppe <roger.peppe at canonical.com> wrote:
> On 30 October 2014 14:34, Eric Snow <eric.snow at canonical.com> wrote:
>> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe <roger.peppe at canonical.com> wrote:
>>> It's a pity then that if you "go get" a package, origin is the repo
>>> you've branched from. There is always one of those, but you
>>> don't necessary have a fork of the repo yourself.
>>
>> Why wouldn't you want go get to fetch from your clone by default?
>
> What Andrew said.
>
> Also, the only information that "go get" has when a repository
> doesn't exist locally is the home of that repository.
> So when "go get" gets a new package, the only place
> that origin can point to is that repository's home.

Right.  I'm not suggesting that "go get" (or godeps) change the
remotes for a repo that didn't already have a local clone, nor even
for any existing local clones.  In fact, I'm saying that the current
behavior of "go get" is just fine.  It shouldn't need to worry about
any other remotes than "origin", regardless of if the local clone
already existed.  Neither should it worry about where "origin" is
pointing, nor about syncing origin with upstream.

If someone has pointed "origin" to point to their own remote [1] clone
(which is what the juju CONTRIBUTING doc suggests), then they are
responsible for keeping that synced up with upstream.  If they don't
and godeps has issues because it can't find the revision it wants,
that isn't the fault of godeps or "go get".

I believe the request from earlier (Tim?) is that godeps help out in
that case. [2][3]  However, that should not require that "go get" have
any awareness of remotes.

>
> When starting work on a package, the first thing I will do is
> invariably "go get" that package, which will fetch all new dependencies
> too. For the majority of those dependencies, I won't already
> have forked them on github. If I come to start work on
> one of those dependencies, it will already have an "origin"
> remote pointing to the source of the repo.
>
> So it's much easier IMHO just to go with the flow and keep origin
> always meaning the same thing, whether you've forked the
> repo or not.

Right.  That is fine and should not change, nor need to.  It's the
case where you did change your remotes that godeps *could* be more
helpful, regardless of whether or not it's worth doing.

-eric

[1] I suppose you could also point "origin" to another repo elsewhere
on your local filesystem.
[2] I was going to pull this conversation into a feature request on
the godeps issue tracker, since it is basically a distraction from the
original thread topic.  However, I didn't find any such tracker.  The
launchpad project does not seem to have one enabled and there is no
github repo,
[3] Regarding the feature request, here's a possible solution.  If the
revision for a repo is not found in "origin" (after running "go get"),
look for it in "upstream" (if that remote exists).  If "upstream"
exists but the revision isn't there, give a warning that "upstream"
may be out of date.  I suppose godeps could also try fetching from
upstream first (without pushing any changes to upstream).