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" <[email protected]> wrote: > On Thu, Jun 5, 2014 at 9:28 PM, roger peppe <[email protected]> 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 <[email protected]> wrote: >> > On 5 June 2014 14:20, Nate Finch <[email protected]> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
