search

mediocregopher / goat

A simple, yaml-based go dependency manager
Apache License 2.0
68 stars 11 forks source link

Code organization changes I'd like to try. #6

Closed trans closed 11 years ago

trans commented 11 years ago

Going over the code, I notice that it is broken down into a few different sub-packages (common, env, deps, main), and yet there is no goat package. Given the size of the code base, I don't think it needs to be that compartmentalized. If it gets too large at a later time we can consider breaking it out, but for now do you mind if I just simplify the code into a single goat package? (and a main of course for the executable) Note, I have already tried it out in my fork and to me it seems to make the code much easier to navigate.

Also, in doing so, I've looked at a number of other popular Go project's to get an idea of how they are doing things. The conventional approach is clearly to organize projects in much the same way as C developers organize their code, which means having a least one *.go file at the toplevel. This file acts as the primary package "interface", so the import path is very simple. e.g. in goat's case that would be github.com/mediocregopher/goat --no need for extraneous /goat/src/goat/. Would it be okay to make this so too? We can always change things again if you don't like it.

mediocregopher commented 11 years ago

I'm totally in favor of getting rid of /goat/src/goat/. I used to do that in my projects, but I've since realized it's just a waste of space.

As for getting rid of the sub-packages I'm less in favor of that. I will admit that maybe my choice of sub-packages is less than ideal and could be re-organized, but even for a small codebase having sub-packages makes it easier to reason about and expand later. I've worked on two or three go projects now where I ended up having to expand a single package into multiple ones and it was not trivial at all, especially since go doesn't allow for circular dependencies. Having things in a tree-like structure from the get-go is helpful in the long-run.

mediocregopher commented 11 years ago

How about this though: in the next couple days I'm gonna start a v1.0 branch to implement all the changes we've been talking about, during which I'll probably change the structure pretty significantly because I see a lot of ways I could organize things better (namely, break up that env package). When I get an alpha version of that going I'll shoot you an email at the address on your profile and you can tell me what you think :)

trans commented 11 years ago

Sounds great. Have a look at what I've been trying out (https://github.com/openbohemians/goat) while you're at it. Maybe it can contribute some ideas to your approach.

mediocregopher commented 11 years ago

Alright, will do. Thanks for all the help and ideas so far!