Feature Request: Refactor main.go into packages for easy downstream integration

[volatiletech]

Feature Request: Refactor main.go into packages for easy downstream integration

[aarondl]

@cornfeedhobo We've actually refactored main.go away from most of the useful code. boilingcore is now the package that has the useful things. Main.go now only contains command line arg / config logic which you could pretty easily replicate. Maybe that works for you?

[aarondl]

Hey there @cornfeedhobo.

I'd be okay with this but let's talk it out some first. We even had this structure at one point (cmd folder and with the lib front and center) but we dropped it because it wasn't useful to anyone since the binary is really what people are after when you go get the project so we got rid of it for the vanity path.

The first thing I want to clarify is how sqlboiler is intended to be used. The binary sqlboiler is only for generation and only has to be used when your database changes. It's very easy to create a script "update-models" (or make piece) that will basically do the following (your single binary could do the same via exec):

go get -u -t github.com/vattle/sqlboiler # install latest binary
glide update # or what have you for updating your vendored copies from GOPATH
go generate

The other question is, is there any way we can discourage this path? We try to take our versioning seriously and have been delivering good fixes so unless you have CI delivering this single binary you'd be missing these fixes until someone noticed you needed an update. We could create a binary install that comes with the templates in the same directory. Maybe an install script? Would this make it better or worse? Just looking for ideas here :)

So, if none of the above solves your problems and you still want to proceed down this path:

One of the problems to consider is the management of the template files. First off loading them may be a chore since currently we just glob up the directories. If you were to do a single binary install of it there'd have to be some sort of provider implementation for the people who use it now from the fs and for people who use some sort of single binary style (I assume you're using gobindata or something?). This is the main issue.

I'd want to keep the vanity go get path we have now, so we wouldn't move to the cmd/sqlboiler package style probably because most people will still be using it as it's used today.

Thoughts?

[nullbio]

Closing due to inactivity. Please re-open if you (or anyone else) is still interested in this.

[cornfeedhobo]

@aarondl Sorry I did not respond at the time.

I guess all I can say is that I think all your points are good, but I value embedding and versioning over asking teammates to update sqlboiler directly, and I am not certain it's something you need to discourage.
I have a work around that works, but it would be nice to not work around this.

I've been exploring this other framework that also uses generation, and I like their solution to folks that want to vendor like me. https://goa.design/design/vendoring/

Thanks again for all the hard work.

[cornfeedhobo]

@aarondl Yes I am looking into that now. thank you again!!