Re: how to update dependencies.tsv

[Andrew Wilkins]

On Mon, Nov 10, 2014 at 6:02 AM, Tim Penhey 
wrote:

> I'm more interested in a solution that works for everyone rather than
> pointing fingers.
>
> Given that our current docs suggest specifying origin to personal repo,
> and upstream to the juju ones, is there any way we can configure the
> local repo such that when we say 'git fetch' it fetches from upstream
> rather than origin?
>

>From "git help fetch":

"When no remote is specified, by default the origin remote will be used,
unless there’s an upstream branch configured for the current branch."

The only times I've had trouble with "godeps -u" is when I've not set the
upstream branch correctly. Here's how you can do that:

$ # initially no upstream set
$ git fetch -v
>From github.com:axw/juju
(noise)

$ git branch -vv | grep \*
* icantbelieveitsnotmaster  fc54097 Merge pull
request #1070 from axw/lp1362072-azure-verify-credentials
$ git remote -v
origin g...@github.com:axw/juju.git (fetch)
origin g...@github.com:axw/juju.git (push)
upstream g...@github.com:juju/juju.git (fetch)
upstream no-pushing (push)
$ git branch --set-upstream-to upstream/master
Branch icantbelieveitsnotmaster set up to track remote branch master from
upstream.
$ git branch -vv | grep \*
* icantbelieveitsnotmaster  fc54097
[upstream/master] Merge pull request #1070 from
axw/lp1362072-azure-verify-credentials

$ # git fetch will now go to the right place
$ git fetch -v
(noise)
>From github.com:juju/juju
(noise)

Cheers,
Andrew

Failing that, I'd suggest that we change our docs so we don't break our
> contributors.
>
> The problem is that right now, someone following our docs will get a
> broken experience.
>
> Tim
>
> On 30/10/14 23:40, roger peppe wrote:
> > On 30 October 2014 09:47, Nate Finch  wrote:
> >> Upstream and origin are very very common in the git world. Most any how
> to
> >> or stack overflow answer uses those by default. Origin is your repo and
> >> upstream is the repo you branched from.   I started out doing it your
> way,
> >> Roger, since I agree that information does flow both ways, and naming my
> >> repo after myself made sense, but I got so annoyed with every answer I
> >> looked up using origin and upstream that I changed to just use those
> terms.
> >>
> >> Using standard terms is a good thing so we all know what we're talking
> >> about.
> >
> > 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.
> >
> > Hence I think that it's worth reconsidering this for our Go-centric
> world.
> > It's good to have things work correctly by default.
> >
> > Also, as I said, godeps doesn't have any special preference for
> > upstream or origin - it just does a git fetch.
> >
> > It's interesting to read in the comments on the top answer
> > in this SO question:
> >
> http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github
> > :
> >
> > "It is worth mentioning in context of github it makes more sense to
> > have origin be the master-repo and use github username as the remote
> > name for your and other forks. Tools like defunkt.io/hub does this and
> > makes working with repositories and collaborating across forks much
> > more uniform."
> >
> > So I'm not the only one that feels this way.
> >
> >> On Oct 30, 2014 4:22 AM, "roger peppe" 
> wrote:
> >>>
> >>> On 29 October 2014 21:03, Tim Penhey  wrote:
>  On 30/10/14 01:11, roger peppe wrote:
> > A better solution here, which I've been meaning to do for a while,
> > would be to change godeps so that it can explore all possible
> > targets. I had a go at that this morning (just adding all tags to
> > build.Context) but it's not quite as easy as that. I should
> > be able to fix it soon though.
> 
>  While you are looking at godeps, I don't suppose you can fix it so it
>  looks for the upstream remote?
> >>>
> >>> As things currently are, godeps doesn't know about any remote
> >>> in particular, and I think that's probably correct - it just uses
> >>> "git fetch" (with no arguments) to fetch, and relies on the
> >>> defaults for that.
> >>>
>  I was told that we should have the origin remote being our personal
>  github repo and upstream being the team repo.
> >>>
> >>> I actually think that this is not a great way to configure things.
> >>> When you clone a git repository (for example by doing "go get")
> >>> there is only one remote configured, and that's "origin".
> >>>
> >>> So if I changed godeps to pull from upstream, it would have to
> >>> fall back to pulling from origin in this, the most common case.
> >>>
> >>> Personally, I find the very word "upstream" confusing when
> >>> used in this area - information flows both ways. The
> >>> one certainty is that everything is destined for the
> >>> main repo, so naming that "origin" mak

Re: how to update dependencies.tsv

[Tim Penhey]

I'm more interested in a solution that works for everyone rather than
pointing fingers.

Given that our current docs suggest specifying origin to personal repo,
and upstream to the juju ones, is there any way we can configure the
local repo such that when we say 'git fetch' it fetches from upstream
rather than origin?

Failing that, I'd suggest that we change our docs so we don't break our
contributors.

The problem is that right now, someone following our docs will get a
broken experience.

Tim

On 30/10/14 23:40, roger peppe wrote:
> On 30 October 2014 09:47, Nate Finch  wrote:
>> Upstream and origin are very very common in the git world. Most any how to
>> or stack overflow answer uses those by default. Origin is your repo and
>> upstream is the repo you branched from.   I started out doing it your way,
>> Roger, since I agree that information does flow both ways, and naming my
>> repo after myself made sense, but I got so annoyed with every answer I
>> looked up using origin and upstream that I changed to just use those terms.
>>
>> Using standard terms is a good thing so we all know what we're talking
>> about.
> 
> 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.
> 
> Hence I think that it's worth reconsidering this for our Go-centric world.
> It's good to have things work correctly by default.
> 
> Also, as I said, godeps doesn't have any special preference for
> upstream or origin - it just does a git fetch.
> 
> It's interesting to read in the comments on the top answer
> in this SO question:
> http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github
> :
> 
> "It is worth mentioning in context of github it makes more sense to
> have origin be the master-repo and use github username as the remote
> name for your and other forks. Tools like defunkt.io/hub does this and
> makes working with repositories and collaborating across forks much
> more uniform."
> 
> So I'm not the only one that feels this way.
> 
>> On Oct 30, 2014 4:22 AM, "roger peppe"  wrote:
>>>
>>> On 29 October 2014 21:03, Tim Penhey  wrote:
 On 30/10/14 01:11, roger peppe wrote:
> A better solution here, which I've been meaning to do for a while,
> would be to change godeps so that it can explore all possible
> targets. I had a go at that this morning (just adding all tags to
> build.Context) but it's not quite as easy as that. I should
> be able to fix it soon though.

 While you are looking at godeps, I don't suppose you can fix it so it
 looks for the upstream remote?
>>>
>>> As things currently are, godeps doesn't know about any remote
>>> in particular, and I think that's probably correct - it just uses
>>> "git fetch" (with no arguments) to fetch, and relies on the
>>> defaults for that.
>>>
 I was told that we should have the origin remote being our personal
 github repo and upstream being the team repo.
>>>
>>> I actually think that this is not a great way to configure things.
>>> When you clone a git repository (for example by doing "go get")
>>> there is only one remote configured, and that's "origin".
>>>
>>> So if I changed godeps to pull from upstream, it would have to
>>> fall back to pulling from origin in this, the most common case.
>>>
>>> Personally, I find the very word "upstream" confusing when
>>> used in this area - information flows both ways. The
>>> one certainty is that everything is destined for the
>>> main repo, so naming that "origin" makes sense to me.
>>>
>>> I never create a repo named "upstream" - I have "origin"
>>> and I name other remotes after github users, e.g. "rogpeppe",
>>> which seems to scale better when I'm collaborating with
>>> other people.
>>>
 When godeps tries to pull in new revisions into a repo where I have the
 remotes set as I was told to, godeps fails to pull in new revisions and
 I normally do something like:

   (cd ../names && git fetch upstream master)

 Then run the godeps command again.
>>>
>>> All the above said, I don't think there's anything stopping you from using
>>> this. Just do:
>>>
>>> git branch --set-upstream-to upstream/master
>>>
>>> and I think it should work (though I haven't actually tried it)
>>>
>>>   cheers,
>>> rog.


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[roger peppe]

On 31 October 2014 15:48, Eric Snow  wrote:
> On Fri, Oct 31, 2014 at 2:11 AM, roger peppe  
> wrote:
>> On 30 October 2014 14:34, Eric Snow  wrote:
>>> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe  
>>> 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.

I don't see how I could do that. To pull from a different remote,
godeps would presumably have to name that remote (i.e. "be aware" of
it).

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

That's a good point. I hadn't realised that it was necessary
to enable bug tracking explicitly in launchpad. That's done
now - feel free to report bugs.

> [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).

I guess it could always try to fetch all configured remotes (perhaps
concurrently) if the initial godeps fetch fails. That has the
potential disadvantage that some remotes might be badly configured and
hang up though.

Probably easier just to make sure that your default upstream is
configured correctly.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Nate Finch]

FWIW, I always branch off upstream/master.  I don't have master synced to
my repo, because it just seems like an extra step.  Why not go straight to
the source?
On Oct 31, 2014 11:48 AM, "Eric Snow"  wrote:

> On Fri, Oct 31, 2014 at 2:11 AM, roger peppe 
> wrote:
> > On 30 October 2014 14:34, Eric Snow  wrote:
> >> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe 
> 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).
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Eric Snow]

On Fri, Oct 31, 2014 at 2:11 AM, roger peppe  wrote:
> On 30 October 2014 14:34, Eric Snow  wrote:
>> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe  
>> 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).

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Eric Snow]

On Thu, Oct 30, 2014 at 8:36 PM, Andrew Wilkins
 wrote:
> On Thu, Oct 30, 2014 at 10:34 PM, Eric Snow  wrote:
>> Why wouldn't you want go get to fetch from your clone by default?
>> Naturally master on origin should be match upstream, which may require
>> you to pull-upstream-push-origin.
>
> Why naturally? I don't use "master" in my fork of juju, I just use
> feature/bug branches.
> The "master" branch in my repo tracks upstream/master.

Agreed.  I don't commit anything to master either.  However, all my
branches are based on master (or another upstream branch), which I
expect is the case for everyone.  If local master isn't in sync with
upstream (regardless of what you call the remote) then I don't see how
there can be as much confidence that any "feature" branches are valid
for merging upstream.  Hence "naturally".  Sorry I was unclear or if I
misunderstood.

-eric

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[roger peppe]

On 30 October 2014 14:34, Eric Snow  wrote:
> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe  
> 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.

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.

FWIW I never use "git clone" to copy Go package repositories
locally.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Andrew Wilkins]

On Thu, Oct 30, 2014 at 10:34 PM, Eric Snow  wrote:

> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe 
> 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?
> Naturally master on origin should be match upstream, which may require
> you to pull-upstream-push-origin.


Why naturally? I don't use "master" in my fork of juju, I just use
feature/bug branches.
The "master" branch in my repo tracks upstream/master.

For local clones in my $GOPATH
> where I'm not doing development (i.e. ones created by go get), I don't
> have upstream set and origin still points to github (or wherever).  So
> the behavior of go get works fine for me.
>
> As to making godeps honor the "upstream" remote, the focus for godeps
> should be on what's in each official repo.  The revisions in our
> dependencies.tsv should be coming only from there.  If it's
> conventional to use "upstream" for those official remotes (it *is* our
> recommended convention in {juju}/CONTRIBUTING), then it would be nice
> for godeps to try it first.  The alternative is that folks be more
> diligent about making sure their "origin" clones are up-to-date with
> upstream, which is sometimes easy to do before running godeps.
>
> -eric
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Eric Snow]

On Thu, Oct 30, 2014 at 4:40 AM, roger peppe  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?
Naturally master on origin should be match upstream, which may require
you to pull-upstream-push-origin.  For local clones in my $GOPATH
where I'm not doing development (i.e. ones created by go get), I don't
have upstream set and origin still points to github (or wherever).  So
the behavior of go get works fine for me.

As to making godeps honor the "upstream" remote, the focus for godeps
should be on what's in each official repo.  The revisions in our
dependencies.tsv should be coming only from there.  If it's
conventional to use "upstream" for those official remotes (it *is* our
recommended convention in {juju}/CONTRIBUTING), then it would be nice
for godeps to try it first.  The alternative is that folks be more
diligent about making sure their "origin" clones are up-to-date with
upstream, which is sometimes easy to do before running godeps.

-eric

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Gustavo Niemeyer]

I have never used "upstream" as an actual remote name. I see people
commonly using the term as a wildcard to refer to the "upstream branch"
whatever it is. The term is also used widely in git itself with the same
meaning, including in the command line interface. For example, you set the
upstream branch with --set-upstream (or -u for short), and in most cases
people set their origin branch as upstream.

Most posts in StackOverflow follow that:

http://stackoverflow.com/search?q=%5Bgit%5D+upstream

This confirms what Roger pointed out: upstream is well established as a
concept, not as a remote label, so it's best to use a well defined name
that points out where the code was taken from, rather than overloading the
term to mean something else.


On Thu Oct 30 2014 at 7:47:49 AM Nate Finch 
wrote:

> Upstream and origin are very very common in the git world. Most any how to
> or stack overflow answer uses those by default. Origin is your repo and
> upstream is the repo you branched from.   I started out doing it your way,
> Roger, since I agree that information does flow both ways, and naming my
> repo after myself made sense, but I got so annoyed with every answer I
> looked up using origin and upstream that I changed to just use those terms.
>
> Using standard terms is a good thing so we all know what we're talking
> about.
> On Oct 30, 2014 4:22 AM, "roger peppe"  wrote:
>
>> On 29 October 2014 21:03, Tim Penhey  wrote:
>> > On 30/10/14 01:11, roger peppe wrote:
>> >> A better solution here, which I've been meaning to do for a while,
>> >> would be to change godeps so that it can explore all possible
>> >> targets. I had a go at that this morning (just adding all tags to
>> >> build.Context) but it's not quite as easy as that. I should
>> >> be able to fix it soon though.
>> >
>> > While you are looking at godeps, I don't suppose you can fix it so it
>> > looks for the upstream remote?
>>
>> As things currently are, godeps doesn't know about any remote
>> in particular, and I think that's probably correct - it just uses
>> "git fetch" (with no arguments) to fetch, and relies on the
>> defaults for that.
>>
>> > I was told that we should have the origin remote being our personal
>> > github repo and upstream being the team repo.
>>
>> I actually think that this is not a great way to configure things.
>> When you clone a git repository (for example by doing "go get")
>> there is only one remote configured, and that's "origin".
>>
>> So if I changed godeps to pull from upstream, it would have to
>> fall back to pulling from origin in this, the most common case.
>>
>> Personally, I find the very word "upstream" confusing when
>> used in this area - information flows both ways. The
>> one certainty is that everything is destined for the
>> main repo, so naming that "origin" makes sense to me.
>>
>> I never create a repo named "upstream" - I have "origin"
>> and I name other remotes after github users, e.g. "rogpeppe",
>> which seems to scale better when I'm collaborating with
>> other people.
>>
>> > When godeps tries to pull in new revisions into a repo where I have the
>> > remotes set as I was told to, godeps fails to pull in new revisions and
>> > I normally do something like:
>> >
>> >   (cd ../names && git fetch upstream master)
>> >
>> > Then run the godeps command again.
>>
>> All the above said, I don't think there's anything stopping you from using
>> this. Just do:
>>
>> git branch --set-upstream-to upstream/master
>>
>> and I think it should work (though I haven't actually tried it)
>>
>>   cheers,
>> rog.
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[roger peppe]

On 30 October 2014 09:47, Nate Finch  wrote:
> Upstream and origin are very very common in the git world. Most any how to
> or stack overflow answer uses those by default. Origin is your repo and
> upstream is the repo you branched from.   I started out doing it your way,
> Roger, since I agree that information does flow both ways, and naming my
> repo after myself made sense, but I got so annoyed with every answer I
> looked up using origin and upstream that I changed to just use those terms.
>
> Using standard terms is a good thing so we all know what we're talking
> about.

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.

Hence I think that it's worth reconsidering this for our Go-centric world.
It's good to have things work correctly by default.

Also, as I said, godeps doesn't have any special preference for
upstream or origin - it just does a git fetch.

It's interesting to read in the comments on the top answer
in this SO question:
http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github
:

"It is worth mentioning in context of github it makes more sense to
have origin be the master-repo and use github username as the remote
name for your and other forks. Tools like defunkt.io/hub does this and
makes working with repositories and collaborating across forks much
more uniform."

So I'm not the only one that feels this way.

> On Oct 30, 2014 4:22 AM, "roger peppe"  wrote:
>>
>> On 29 October 2014 21:03, Tim Penhey  wrote:
>> > On 30/10/14 01:11, roger peppe wrote:
>> >> A better solution here, which I've been meaning to do for a while,
>> >> would be to change godeps so that it can explore all possible
>> >> targets. I had a go at that this morning (just adding all tags to
>> >> build.Context) but it's not quite as easy as that. I should
>> >> be able to fix it soon though.
>> >
>> > While you are looking at godeps, I don't suppose you can fix it so it
>> > looks for the upstream remote?
>>
>> As things currently are, godeps doesn't know about any remote
>> in particular, and I think that's probably correct - it just uses
>> "git fetch" (with no arguments) to fetch, and relies on the
>> defaults for that.
>>
>> > I was told that we should have the origin remote being our personal
>> > github repo and upstream being the team repo.
>>
>> I actually think that this is not a great way to configure things.
>> When you clone a git repository (for example by doing "go get")
>> there is only one remote configured, and that's "origin".
>>
>> So if I changed godeps to pull from upstream, it would have to
>> fall back to pulling from origin in this, the most common case.
>>
>> Personally, I find the very word "upstream" confusing when
>> used in this area - information flows both ways. The
>> one certainty is that everything is destined for the
>> main repo, so naming that "origin" makes sense to me.
>>
>> I never create a repo named "upstream" - I have "origin"
>> and I name other remotes after github users, e.g. "rogpeppe",
>> which seems to scale better when I'm collaborating with
>> other people.
>>
>> > When godeps tries to pull in new revisions into a repo where I have the
>> > remotes set as I was told to, godeps fails to pull in new revisions and
>> > I normally do something like:
>> >
>> >   (cd ../names && git fetch upstream master)
>> >
>> > Then run the godeps command again.
>>
>> All the above said, I don't think there's anything stopping you from using
>> this. Just do:
>>
>> git branch --set-upstream-to upstream/master
>>
>> and I think it should work (though I haven't actually tried it)
>>
>>   cheers,
>> rog.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Nate Finch]

Upstream and origin are very very common in the git world. Most any how to
or stack overflow answer uses those by default. Origin is your repo and
upstream is the repo you branched from.   I started out doing it your way,
Roger, since I agree that information does flow both ways, and naming my
repo after myself made sense, but I got so annoyed with every answer I
looked up using origin and upstream that I changed to just use those terms.

Using standard terms is a good thing so we all know what we're talking
about.
On Oct 30, 2014 4:22 AM, "roger peppe"  wrote:

> On 29 October 2014 21:03, Tim Penhey  wrote:
> > On 30/10/14 01:11, roger peppe wrote:
> >> A better solution here, which I've been meaning to do for a while,
> >> would be to change godeps so that it can explore all possible
> >> targets. I had a go at that this morning (just adding all tags to
> >> build.Context) but it's not quite as easy as that. I should
> >> be able to fix it soon though.
> >
> > While you are looking at godeps, I don't suppose you can fix it so it
> > looks for the upstream remote?
>
> As things currently are, godeps doesn't know about any remote
> in particular, and I think that's probably correct - it just uses
> "git fetch" (with no arguments) to fetch, and relies on the
> defaults for that.
>
> > I was told that we should have the origin remote being our personal
> > github repo and upstream being the team repo.
>
> I actually think that this is not a great way to configure things.
> When you clone a git repository (for example by doing "go get")
> there is only one remote configured, and that's "origin".
>
> So if I changed godeps to pull from upstream, it would have to
> fall back to pulling from origin in this, the most common case.
>
> Personally, I find the very word "upstream" confusing when
> used in this area - information flows both ways. The
> one certainty is that everything is destined for the
> main repo, so naming that "origin" makes sense to me.
>
> I never create a repo named "upstream" - I have "origin"
> and I name other remotes after github users, e.g. "rogpeppe",
> which seems to scale better when I'm collaborating with
> other people.
>
> > When godeps tries to pull in new revisions into a repo where I have the
> > remotes set as I was told to, godeps fails to pull in new revisions and
> > I normally do something like:
> >
> >   (cd ../names && git fetch upstream master)
> >
> > Then run the godeps command again.
>
> All the above said, I don't think there's anything stopping you from using
> this. Just do:
>
> git branch --set-upstream-to upstream/master
>
> and I think it should work (though I haven't actually tried it)
>
>   cheers,
> rog.
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[roger peppe]

On 29 October 2014 21:03, Tim Penhey  wrote:
> On 30/10/14 01:11, roger peppe wrote:
>> A better solution here, which I've been meaning to do for a while,
>> would be to change godeps so that it can explore all possible
>> targets. I had a go at that this morning (just adding all tags to
>> build.Context) but it's not quite as easy as that. I should
>> be able to fix it soon though.
>
> While you are looking at godeps, I don't suppose you can fix it so it
> looks for the upstream remote?

As things currently are, godeps doesn't know about any remote
in particular, and I think that's probably correct - it just uses
"git fetch" (with no arguments) to fetch, and relies on the
defaults for that.

> I was told that we should have the origin remote being our personal
> github repo and upstream being the team repo.

I actually think that this is not a great way to configure things.
When you clone a git repository (for example by doing "go get")
there is only one remote configured, and that's "origin".

So if I changed godeps to pull from upstream, it would have to
fall back to pulling from origin in this, the most common case.

Personally, I find the very word "upstream" confusing when
used in this area - information flows both ways. The
one certainty is that everything is destined for the
main repo, so naming that "origin" makes sense to me.

I never create a repo named "upstream" - I have "origin"
and I name other remotes after github users, e.g. "rogpeppe",
which seems to scale better when I'm collaborating with
other people.

> When godeps tries to pull in new revisions into a repo where I have the
> remotes set as I was told to, godeps fails to pull in new revisions and
> I normally do something like:
>
>   (cd ../names && git fetch upstream master)
>
> Then run the godeps command again.

All the above said, I don't think there's anything stopping you from using
this. Just do:

git branch --set-upstream-to upstream/master

and I think it should work (though I haven't actually tried it)

  cheers,
rog.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Nate Finch]

We should change the make target to always run and change the CI machines
so they can run it,  and test that dependencies.tsv is correct. It's crazy
that we don't do that now. The only reason the build even works now is a
happy accident (and constant fixes to dependencies.tsv when it breaks)
On Oct 29, 2014 5:01 PM, "Tim Penhey"  wrote:

> On 29/10/14 21:05, Dimiter Naydenov wrote:
> > On 29.10.2014 09:46, David Cheney wrote:
> >> Does your $GOPATH include more than one entry ?
> > No, it only has a single path.
> >
> >
> >> The make target should probably just expect godeps to be in your
> >> $PATH.
> > That's a good point. I did some experiments adding:
> > GODEPS := $(shell which godeps)
> >
> > at the beginning and then trying to use it. I found out what the
> > problem was - apparently the Makefile was written with the idea that
> > godeps shouldn't be called unless JUJU_MAKE_GODEPS is set to true.
> >
> > With the following patch, I can now run "make godeps" and related
> > targets without an issue:
>
> The reason for the "default off" switch was due to the CI builders and
> test machines.
>
> We need to be a little careful here.
>
> When this came out yesterday, I tried to run godeps with the flag
> specified above to make the makefile just work, but since I didn't have
> the repo at all, it just failed.  And I stopped working on it and threw
> away the branch.
>
> Happy to review makefile changes though.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Tim Penhey]

On 30/10/14 01:11, roger peppe wrote:
> A better solution here, which I've been meaning to do for a while,
> would be to change godeps so that it can explore all possible
> targets. I had a go at that this morning (just adding all tags to
> build.Context) but it's not quite as easy as that. I should
> be able to fix it soon though.

While you are looking at godeps, I don't suppose you can fix it so it
looks for the upstream remote?

I was told that we should have the origin remote being our personal
github repo and upstream being the team repo.

When godeps tries to pull in new revisions into a repo where I have the
remotes set as I was told to, godeps fails to pull in new revisions and
I normally do something like:

  (cd ../names && git fetch upstream master)

Then run the godeps command again.

Tim


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Tim Penhey]

On 29/10/14 21:05, Dimiter Naydenov wrote:
> On 29.10.2014 09:46, David Cheney wrote:
>> Does your $GOPATH include more than one entry ?
> No, it only has a single path.
> 
> 
>> The make target should probably just expect godeps to be in your
>> $PATH.
> That's a good point. I did some experiments adding:
> GODEPS := $(shell which godeps)
> 
> at the beginning and then trying to use it. I found out what the
> problem was - apparently the Makefile was written with the idea that
> godeps shouldn't be called unless JUJU_MAKE_GODEPS is set to true.
> 
> With the following patch, I can now run "make godeps" and related
> targets without an issue:

The reason for the "default off" switch was due to the CI builders and
test machines.

We need to be a little careful here.

When this came out yesterday, I tried to run godeps with the flag
specified above to make the makefile just work, but since I didn't have
the repo at all, it just failed.  And I stopped working on it and threw
away the branch.

Happy to review makefile changes though.

Tim

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Curtis Hovey-Canonical]

On Tue, Oct 28, 2014 at 11:58 PM, John Meinel  wrote:
> can we please just have "make dependencies.tsv" do the right thing so we
> don't have to remember which set of flags and env vars we need to use this
> time?
>
> I'm also not 100% sure that we'll have even downloaded all the windows
> dependencies if they are a "strict superset" given that you are running "go
> get" on a Linux machine to start with.

I think it works. The release tarball we tested was created on the
juju-ci, the jenkins master, then we built the win client and agent 10
minutes later.



-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Nate Finch]

That would be awesome.
On Oct 29, 2014 8:11 AM, "roger peppe"  wrote:

> A better solution here, which I've been meaning to do for a while,
> would be to change godeps so that it can explore all possible
> targets. I had a go at that this morning (just adding all tags to
> build.Context) but it's not quite as easy as that. I should
> be able to fix it soon though.
>
> On 29 October 2014 10:10, Nate Finch  wrote:
> > We certainly should add a makefile target.  I looked into it briefly
> > yesterday, but didn't get far, as I haven't used makefiles since college,
> > and didn't want to muck it up.
> >
> > As for point two, yes, that's a problem. We should add GOOS=windows go
> get
> > -t -u github.com/juju/juju/... to the makefile target that gets the
> > dependencies, and it'll download the windows dependencies as well as the
> > linux ones.
> >
> > On Tue, Oct 28, 2014 at 11:58 PM, John Meinel 
> > wrote:
> >>
> >> can we please just have "make dependencies.tsv" do the right thing so we
> >> don't have to remember which set of flags and env vars we need to use
> this
> >> time?
> >>
> >> I'm also not 100% sure that we'll have even downloaded all the windows
> >> dependencies if they are a "strict superset" given that you are running
> "go
> >> get" on a Linux machine to start with.
> >>
> >> John
> >> =:->
> >>
> >>
> >> On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch 
> >> wrote:
> >>>
> >>> We have a few windows dependencies that are not (and in some cases can
> >>> not be) imported for the linux build.  Luckily, the windows
> dependencies are
> >>> a strict super set of the linux dependencies, so we can still use
> godeps to
> >>> create dependencies.tsv, just by setting GOOS first, thusly (from the
> root
> >>> of github.com/juju/juju):
> >>>
> >>> GOOS=windows godeps -t ./... > dependencies.tsv
> >>>
> >>> Please use this command line when updating dependencies.tsv so that is
> >>> keeps a standard format which will minimize conflicts in the file.
> >>>
> >>> -Nate
> >>>
> >>> --
> >>> Juju-dev mailing list
> >>> Juju-dev@lists.ubuntu.com
> >>> Modify settings or unsubscribe at:
> >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>
> >>
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[roger peppe]

A better solution here, which I've been meaning to do for a while,
would be to change godeps so that it can explore all possible
targets. I had a go at that this morning (just adding all tags to
build.Context) but it's not quite as easy as that. I should
be able to fix it soon though.

On 29 October 2014 10:10, Nate Finch  wrote:
> We certainly should add a makefile target.  I looked into it briefly
> yesterday, but didn't get far, as I haven't used makefiles since college,
> and didn't want to muck it up.
>
> As for point two, yes, that's a problem. We should add GOOS=windows go get
> -t -u github.com/juju/juju/... to the makefile target that gets the
> dependencies, and it'll download the windows dependencies as well as the
> linux ones.
>
> On Tue, Oct 28, 2014 at 11:58 PM, John Meinel 
> wrote:
>>
>> can we please just have "make dependencies.tsv" do the right thing so we
>> don't have to remember which set of flags and env vars we need to use this
>> time?
>>
>> I'm also not 100% sure that we'll have even downloaded all the windows
>> dependencies if they are a "strict superset" given that you are running "go
>> get" on a Linux machine to start with.
>>
>> John
>> =:->
>>
>>
>> On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch 
>> wrote:
>>>
>>> We have a few windows dependencies that are not (and in some cases can
>>> not be) imported for the linux build.  Luckily, the windows dependencies are
>>> a strict super set of the linux dependencies, so we can still use godeps to
>>> create dependencies.tsv, just by setting GOOS first, thusly (from the root
>>> of github.com/juju/juju):
>>>
>>> GOOS=windows godeps -t ./... > dependencies.tsv
>>>
>>> Please use this command line when updating dependencies.tsv so that is
>>> keeps a standard format which will minimize conflicts in the file.
>>>
>>> -Nate
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Nate Finch]

We certainly should add a makefile target.  I looked into it briefly
yesterday, but didn't get far, as I haven't used makefiles since college,
and didn't want to muck it up.

As for point two, yes, that's a problem. We should add GOOS=windows go get
-t -u github.com/juju/juju/... to the makefile target that gets the
dependencies, and it'll download the windows dependencies as well as the
linux ones.

On Tue, Oct 28, 2014 at 11:58 PM, John Meinel 
wrote:

> can we please just have "make dependencies.tsv" do the right thing so we
> don't have to remember which set of flags and env vars we need to use this
> time?
>
> I'm also not 100% sure that we'll have even downloaded all the windows
> dependencies if they are a "strict superset" given that you are running "go
> get" on a Linux machine to start with.
>
> John
> =:->
>
>
> On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch 
> wrote:
>
>> We have a few windows dependencies that are not (and in some cases can
>> not be) imported for the linux build.  Luckily, the windows dependencies
>> are a strict super set of the linux dependencies, so we can still use
>> godeps to create dependencies.tsv, just by setting GOOS first, thusly (from
>> the root of github.com/juju/juju):
>>
>> GOOS=windows godeps -t ./... > dependencies.tsv
>>
>> Please use this command line when updating dependencies.tsv so that is
>> keeps a standard format which will minimize conflicts in the file.
>>
>> -Nate
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Dimiter Naydenov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29.10.2014 09:46, David Cheney wrote:
> Does your $GOPATH include more than one entry ?
No, it only has a single path.

> 
> The make target should probably just expect godeps to be in your
> $PATH.
That's a good point. I did some experiments adding:
GODEPS := $(shell which godeps)

at the beginning and then trying to use it. I found out what the
problem was - apparently the Makefile was written with the idea that
godeps shouldn't be called unless JUJU_MAKE_GODEPS is set to true.

With the following patch, I can now run "make godeps" and related
targets without an issue:

diff --git a/Makefile b/Makefile
index 3b6f2ec..4fe7611 100644
- --- a/Makefile
+++ b/Makefile
@@ -37,13 +37,9 @@ ifeq ($(CURDIR),$(PROJECT_DIR))
 ifeq ($(JUJU_MAKE_GODEPS),true)
 $(GOPATH)/bin/godeps:
go get launchpad.net/godeps
- -
+endif
 godeps: $(GOPATH)/bin/godeps
$(GOPATH)/bin/godeps -u dependencies.tsv
- -else
- -godeps:
- -   @echo "skipping godeps"
- -endif

 build: godeps
go build $(PROJECT)/...

Somebody else might find this useful.

As for the "update godeps" target John suggested, I still think it's
the easiest way to do it correctly. E.g. it could be a new target:

+
+updeps: godeps
+   GOOS=windows $(GOPATH)/bin/godeps -t ./... > dependencies.tsv


> 
> On Wed, Oct 29, 2014 at 6:37 PM, Dimiter Naydenov 
>  > wrote:
> 
> +1, in fact there is already a "godeps" target in the Makefile, but
> I never managed to get it working. It's looking for
> $(GOPATH)/bin/godeps binary and I have it right there on my
> machine, but make still claims "File `godeps' does not exist."
> (when running $ make -d godeps).
> 
> Somebody with better make-fu knowledge should probably give a hand 
> with this :)
> 
> On 29.10.2014 05:58, John Meinel wrote:
>> can we please just have "make dependencies.tsv" do the right
>> thing so we don't have to remember which set of flags and env
>> vars we need to use this time?
> 
>> I'm also not 100% sure that we'll have even downloaded all the 
>> windows dependencies if they are a "strict superset" given that
>> you are running "go get" on a Linux machine to start with.
> 
>> John =:->
> 
> 
>> On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch 
>> mailto:nate.fi...@canonical.com>
>  >>
>> wrote:
> 
>> We have a few windows dependencies that are not (and in some
>> cases can not be) imported for the linux build.  Luckily, the
>> windows dependencies are a strict super set of the linux
>> dependencies, so we can still use godeps to create
>> dependencies.tsv, just by setting GOOS first, thusly (from the
>> root of github.com/juju/juju  
>> ):
> 
>> GOOS=windows godeps -t ./... > dependencies.tsv
> 
>> Please use this command line when updating dependencies.tsv so 
>> that is keeps a standard format which will minimize conflicts in 
>> the file.
> 
>> -Nate
> 
>> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
>>  
>>  > Modify settings or unsubscribe
>> at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 
> 
> 
> 
> 
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
>  Modify settings or unsubscribe
> at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 

- -- 
Dimiter Naydenov 
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUUJ/XAAoJENzxV2TbLzHwEEwIAJcohbpcUZ6wVG30bhoMsDRa
NkJaNeMErfEZIHa0kA9iqACXKhLMngS7M/Dbmryuat/X9NFPOkElLLBZnyydhmqv
DcQXU5Sc6s1K1T5UxXH13jJ80JHQgKo5hg0LO/5gnd81R/iz4mQ7ns54uD8hnNfE
D70FcxBIt+kiMXAU0WB/r8kC0++2afrNQQGpvAp8RntGtCNSH501AAkDq0WmtLw/
iq/8uhLD8lixU/uPHG1PxaxAWaDZ3nkkievl+0t9cgYZAe6xQBOYs9DA+pPMSTxS
Oo+dgsakCKeCqv+7zI4D/h754VzaWyvLYsX0ldWpn+12jywWJHZwoznh5Fm6xYA=
=FwVZ
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[David Cheney]

Does your $GOPATH include more than one entry ?

The make target should probably just expect godeps to be in your $PATH.

On Wed, Oct 29, 2014 at 6:37 PM, Dimiter Naydenov <
dimiter.nayde...@canonical.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> +1, in fact there is already a "godeps" target in the Makefile, but I
> never managed to get it working. It's looking for $(GOPATH)/bin/godeps
> binary and I have it right there on my machine, but make still claims
>  "File `godeps' does not exist." (when running $ make -d godeps).
>
> Somebody with better make-fu knowledge should probably give a hand
> with this :)
>
> On 29.10.2014 05:58, John Meinel wrote:
> > can we please just have "make dependencies.tsv" do the right thing
> > so we don't have to remember which set of flags and env vars we
> > need to use this time?
> >
> > I'm also not 100% sure that we'll have even downloaded all the
> > windows dependencies if they are a "strict superset" given that you
> > are running "go get" on a Linux machine to start with.
> >
> > John =:->
> >
> >
> > On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch
> > mailto:nate.fi...@canonical.com>>
> > wrote:
> >
> > We have a few windows dependencies that are not (and in some cases
> > can not be) imported for the linux build.  Luckily, the windows
> > dependencies are a strict super set of the linux dependencies, so
> > we can still use godeps to create dependencies.tsv, just by
> > setting GOOS first, thusly (from the root of github.com/juju/juju
> > ):
> >
> > GOOS=windows godeps -t ./... > dependencies.tsv
> >
> > Please use this command line when updating dependencies.tsv so
> > that is keeps a standard format which will minimize conflicts in
> > the file.
> >
> > -Nate
> >
> > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
> >  Modify settings or unsubscribe
> > at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
> >
>
>
> - --
> Dimiter Naydenov 
> juju-core team
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUUJlIAAoJENzxV2TbLzHwND0IAMS3c79LeWwTDnf6sEyMwTcm
> HdvBxaxEeJLNqv8Sq+mK4jWyMAtmoQ/9Azup7g9DZmb1aJXD94n25nf19NNdBkxi
> wzLBMqq3iEkKY+09js8r5S4ScRMOErBrhL7wd4+PDFTL1y5SeDAacBDCzZQKeQlY
> IRkIfOXjfSpQuALONZNUlToMAuTQzC80gf914QX7DOpKMFhsiS6cMIb2nYlAScEZ
> UFjJwRrTEgjiGoouq/KnmahhYK4i4dsdQDy9a44lTgIb+igoAi6OBzTJ8ktqac+G
> +e+sS25SHJ+T2R+iPtlJnExW3raa9vHxIJQBazB8C/QjLDqrOtzt1XSe5WxlQxs=
> =akp+
> -END PGP SIGNATURE-
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[Dimiter Naydenov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

+1, in fact there is already a "godeps" target in the Makefile, but I
never managed to get it working. It's looking for $(GOPATH)/bin/godeps
binary and I have it right there on my machine, but make still claims
 "File `godeps' does not exist." (when running $ make -d godeps).

Somebody with better make-fu knowledge should probably give a hand
with this :)

On 29.10.2014 05:58, John Meinel wrote:
> can we please just have "make dependencies.tsv" do the right thing
> so we don't have to remember which set of flags and env vars we
> need to use this time?
> 
> I'm also not 100% sure that we'll have even downloaded all the
> windows dependencies if they are a "strict superset" given that you
> are running "go get" on a Linux machine to start with.
> 
> John =:->
> 
> 
> On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch
> mailto:nate.fi...@canonical.com>>
> wrote:
> 
> We have a few windows dependencies that are not (and in some cases 
> can not be) imported for the linux build.  Luckily, the windows 
> dependencies are a strict super set of the linux dependencies, so
> we can still use godeps to create dependencies.tsv, just by
> setting GOOS first, thusly (from the root of github.com/juju/juju 
> ):
> 
> GOOS=windows godeps -t ./... > dependencies.tsv
> 
> Please use this command line when updating dependencies.tsv so
> that is keeps a standard format which will minimize conflicts in
> the file.
> 
> -Nate
> 
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
>  Modify settings or unsubscribe
> at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 
> 


- -- 
Dimiter Naydenov 
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUUJlIAAoJENzxV2TbLzHwND0IAMS3c79LeWwTDnf6sEyMwTcm
HdvBxaxEeJLNqv8Sq+mK4jWyMAtmoQ/9Azup7g9DZmb1aJXD94n25nf19NNdBkxi
wzLBMqq3iEkKY+09js8r5S4ScRMOErBrhL7wd4+PDFTL1y5SeDAacBDCzZQKeQlY
IRkIfOXjfSpQuALONZNUlToMAuTQzC80gf914QX7DOpKMFhsiS6cMIb2nYlAScEZ
UFjJwRrTEgjiGoouq/KnmahhYK4i4dsdQDy9a44lTgIb+igoAi6OBzTJ8ktqac+G
+e+sS25SHJ+T2R+iPtlJnExW3raa9vHxIJQBazB8C/QjLDqrOtzt1XSe5WxlQxs=
=akp+
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: how to update dependencies.tsv

[John Meinel]

can we please just have "make dependencies.tsv" do the right thing so we
don't have to remember which set of flags and env vars we need to use this
time?

I'm also not 100% sure that we'll have even downloaded all the windows
dependencies if they are a "strict superset" given that you are running "go
get" on a Linux machine to start with.

John
=:->


On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch 
wrote:

> We have a few windows dependencies that are not (and in some cases can not
> be) imported for the linux build.  Luckily, the windows dependencies are a
> strict super set of the linux dependencies, so we can still use godeps to
> create dependencies.tsv, just by setting GOOS first, thusly (from the root
> of github.com/juju/juju):
>
> GOOS=windows godeps -t ./... > dependencies.tsv
>
> Please use this command line when updating dependencies.tsv so that is
> keeps a standard format which will minimize conflicts in the file.
>
> -Nate
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev