On Thu, Jun 26, 2014 at 11:23 AM, roger peppe <rogpe...@gmail.com> wrote: > I have a slightly different proposal, inspired by the recent > Go proposal for internal imports (http://golang.org/s/go14internal), > which currently looks like it will actually be implemented. > > We move all public facing APIs into top level packages within > the juju repo, and move everything else under github.com/juju/juju/internal
That would be really helpful for newcomers to the codebase, like me. > > Packages I would suggest should be exported: > > github.com/juju/juju/api // moved from state/api > github.com/juju/juju/cmd/juju > github.com/juju/juju/cmd/jujud > ... (all the other commands, but not the cmd package itself) > github.com/juju/ > github.com/juju/juju/cmd/internal/jujucmd // containing > supercommand.go from current cmd > github.com/juju/juju/juju // but only the API-related pieces > > Some packages would want moving, because they're user-facing > but currently inside packages that we would probably not want to > export: > > github.com/juju/environs/configstore > > is the only one I can think of right now. > > Others would want splitting. For example, the environs package > is a mix between user-facing and internal stuff right now. > It would be great to take out all the user-facing config file stuff > (that might sit > well inside the juju package). > > Still others would benefit from being made available externally. > I think the rpc package is probably one of those that would > sit well inside its own repo. > > Some packages could benefit from having their own internal > directory - the uniter is one of those, for example. The > apiserver too has many sub-packages that should not really > be visible to the rest of juju. > > In the end, we should end up with an API that it might actually be > feasible to stabilise. I'd like juju to move under gopkg.in at some > point, providing useful stability guarantees for external users > that might want to build Go programs based on our code. Regardless of if any of it happens, for me all of this was actually quite useful perspective on juju. Ultimately what would be great is a structure to the code that helps with discoverability, i.e. the code reflects your description above. A reduction in interdependency between components would help in the same way, but that is a more delicate operation and harder to maintain than restructuring the package layout. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
