I've always advocated keeping the main package lean from the start. +1 on making this change.
-dan On Wed, Nov 14, 2018 at 10:06 AM Robert Butts <[email protected]> wrote: > Well, when I originally wrote `traffic_ops_golang`, I just put everything > in the `main` package, with the assumption that we'd move components as > they got big enough. It seems self-evident to me that these should be > packages, very little should go in `main` in any nontrivial Go app. I don't > really see this as a "large structural change," these are 3 single files. > > I don't think we really need to vote and approve every little Go package > change. But I'm certainly not trying to circumvent the voting process, if > anyone else does feel like the need to? > > > On Wed, Nov 14, 2018 at 9:36 AM Fieck, Brennan <[email protected]> > wrote: > > > A couple of days ago I opened a pull request to add an API response to > > Traffic Ops's `/api/?$` endpoint, for the OPTIONS and GET HTTP methods. > The > > form and function of those changes are still works-in-progress, and > > comments on them are welcome, but what I'm asking about today is more > about > > the challenges I faced in creating the endpoint given the way the Go > > code-base for Traffic Ops is structured. > > > > Between Rob Butts and I, we've agreed that there are parts of the 'main' > > package that ought to be made into their own package: particularly > > routes.go, routing.go, routing_test.go, wrappers.go, wrappers_test.go > > should ideally be in their own package(s) - possible all of it would fall > > under the 'routing' package, or perhaps the wrapper code warrants its own > > package. This will allow the list of endpoints and their structure to be > > available to other parts of TO, as well as any client that could > > potentially want that. > > > > With such a large structural change, I don't feel comfortable writing any > > code without asking: does that sound good to everyone? > > > > > > There are a LOT more questions that need answering before that endpoint I > > made could be included, but I feel this is a good place to start. > > >
