naming repos on github

[Nate Finch]

So, there's no tricking the import logic.  The import path has no strict
relation to the package name.   The package name is only defined by the
"package foo" line at the top of every file.  The import path is only
defined by the location on disk.   It is simply by convention that the last
part of the import path is the same as the package name.  They can be
completely different (though this is almost always a bad idea)

For example if you have a file at $GOPATH/src/
github.com/juju/foo-bar.baz/foo.go and a the top of the file is "package
happy", then if you do this:

import "github.com/juju/foo-bar.baz"

Everything in that package would be namespaced with the name "happy"

happy.Foobar{}

There's no real tricking going on... but of course, that makes it almost
impossible to tell where the package happy comes from in the file that
imports foo-bar.baz.

gopkg.in doesn't do anything special in this regard, it just assumes that
it's relatively obvious that if you have import "gopkg.in/happy.v2" that
it's not too hard to guess that the package name is happy (especially if
you do a lot of work with gopkg.in packages).

As for ditching go get... yes and no (mostly no).  go get is not really
intended for use in contributing to an external project.  It's a "download
and install" this application.  If anything, we should be making our code
*more* happy with go get, so if Go developers want to try out juju, they
can do so in an intuitive fashion.  It would also remove a lot of our pain
if we stopped hitting ourselves in the head by breaking trunk of our repos
and depending on godeps to fix up trunk.  IMO godeps should be used on
release branches only, to pin the revision numbers for repeatable builds.
 Trunk of all our repos should always build, the fact that it doesn't is
our own fault.

As for the hackery to get VCS to work... it's not really hackery, it's just
different than in other languages.  Your repo needs to live in a canonical
place on disk.  That place is $GOPATH/src/github.com/juju/juju because
that's the project we're working on.  github.com/juju/juju is effectively
the project name.  What repo and branch VCS pushes to is independent of
that.  Note that your code at $GOPATH/src/github.com/juju/juju is probably
not just pointing at github.com/jameinel/juju, but probably also pointing
at github.com/juju/juju, and probably some branches of
github.com/jameinel/juju.  You have multiple remote repos and multiple
local branches all living in the same spot on disk.

This is not any different than it was on launchpad.  It feels like it
because we're using a new VCS and a new code hosting site, but we'll figure
out the workflows that work well for us and it'll settle down and be like
it always was.

On Thu, Jun 5, 2014 at 10:10 PM, John Meinel <john at arbash-meinel.com> wrote:

> I believe you can trick the import logic with . as it is what gopkg.in is
> doing with versioning. So doing
> import "github.com/foo.bar"
> Comes in automatically as foo.
> So we *could* do:
> github.com/juju/names.juju
> Without having to rename every import.
>
> Given the amount of hackery to maintain the real upstream name matching
> what it would be nice to call it locally, I really wonder about ditching go
> get for something like godep that just builds your local tree in a sane way
> without the punning.
> If you don't use go get, then it only matters the path on disk, and you
> dont end up with
> $GOPATH/github.com/juju/juju
> Which is actually github.com/jameinel/juju, etc
> We could have it just be
> $GOPATH/juju
> We're mostly there anyway because of dependency tracking which isn't
> provided by go get itself.
> It just feels like we pay a lot to the "go get" Daemon and I'm not sure
> its paying in return...
>
> John
> =:->
> On Jun 6, 2014 4:00 AM, "Andrew Wilkins" <andrew.wilkins at canonical.com>
> wrote:
>
>> On Thu, Jun 5, 2014 at 9:28 PM, roger peppe <rogpeppe at gmail.com> wrote:
>>
>>> Unfortunately that means that the import identifier isn't intuitive,
>>> but perhaps that's ok.
>>
>>
>> It's not so different from the "go-thing" convention a lot of people use,
>> where the package name is actually just "thing".
>> If we were to change it to anything, I'd probably go with juju-.
>>
>> On 5 June 2014 14:27, roger peppe <rogpeppe at gmail.com> wrote:
>>> > On 5 June 2014 14:20, Nate Finch <nate.finch at canonical.com> wrote:
>>> >> We're making a lot of standalone repos on github so that teams
>>> external to
>>> >> core can reuse core's code.
>>> >> I think we need to disambiguate between repos that are generally only
>>> of use
>>> >> when working with juju, and repos that are more general purpose.  For
>>> >> example, errgo is a general use package that anyone else could use.
>>> >> However, there are some pretty vague packages under juju that are
>>> really
>>> >> juju only, such as the names package.
>>> >>
>>> >> If anyone has a good idea of how to disambiguate the two, I think it
>>> would
>>> >> be really useful, so we can point people to all the reusable code
>>> that's
>>> >> getting produced by Juju.
>>> >
>>> > Perhaps "juju-*"?
>>> >
>>> > e.g.
>>> > github.com/juju/juju-names.
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140606/a3ca2a22/attachment.html>