Build a `gallium` tool to build and bundle projects about gallium HOT 6 OPEN

I like this proposal a lot. I think a unified gallium tool makes a lot of sense, and I think over time we will have a number of different gallium-specific tasks as you point out, and I agree it will be much better to have a unified tool with a unified interface rather than a collection of different tools. I'm not 100% convinced about code generation, though. I worry that if we encourage users to check the generated code into their vcs then it will be difficult to make API changes since we'll have to somehow update generated code to talk to the new APIs, and I worry that if we encourage users not to check the generated code into their vcs then external tools, like ssa and so forth won't work.

I wonder if the solution is to just have what you described as gallium new - ie a boilerplate generator - and then let users modify and manage the code on their own from there. There could be gallium new --menus to generate boilerplate with a menu system, gallium new --statusbar to generate boilerplate with a status bar icon, and so forth. Users who wanted to structure their code in a different way could then simply work from the docs and write everything themselves.

Thanks for writing this up! Are you thinking of working on this?

from gallium.

@alexflint great!

I'm definitely up for working on this :)

I'm not 100% convinced about code generation, though. I worry that if we encourage users to check the generated code into their vcs then it will be difficult to make API changes since we'll have to somehow update generated code to talk to the new APIs,

Checking-in generated code would actually be better for API changes than asking users to code the main package themselves.

We would generate the code with a big comment saying they must never edit it by hand.

The idea is to allow them to build and bundle the app regardless of whether they have the gallium app installed or with version they have installed. If they wanted to upgrade gallium, they would need to re-generate the code.

and I worry that if we encourage users not to check the generated code into their vcs then external tools, like ssa and so forth won't work.

My worry about keeping the generated code outside of the repo is reproducible builds. I would like somebody to checkout my gallium-based app and be able to build it regardless of whether they have the gallium app installed.

I wonder if the solution is to just have what you described as gallium new - ie a boilerplate generator - and then let users modify and manage the code on their own from there. There could be gallium new --menus to generate boilerplate with a menu system, gallium new --statusbar to generate boilerplate with a status bar icon, and so forth.

There's two different things here in my opinion:

• bootstrapping an app from a template (similar to Rails Application Templates: rails new blog -m http://example.com/template.rb)
• generating boilerplate code (similar to cobra add and rails generate)

Users who wanted to structure their code in a different way could then simply work from the docs and write everything themselves.

That would always be a possibility, yes.

from gallium.

i disagree here.

I feel that codegen is for much later, and there is little point doing it until the actual code is working.
First get the code working, where you write code against the common API.

Then if you do want to do codegen, dont reinvent the wheel. Use goa.
https://github.com/goadesign/goa
Its a proper DSL driven Code Generator.
I have to say though for menus and other stuff, its just easier to write some code against an API.

from gallium.

@joeblew99 generating the main automatically would actually help while working out the APIs, since we can regenerate the templated main as gallium evolves instead of having people amend the main they wrote manually when they have to upgrade.

When talking about codegen here I'm referring to templated code, rather than DSLs. You would write code against an API rather than a DSL.

Regarding goa. It has a very different scope, since it is a DSL for microservices. I'm talking about something different here.

from gallium.

@ernesto-jimenez thanks for the answer.

so can you point me to an example of where we DO or WOULD gen the main ?. I think i generalised in my answer, and now i want to see the exact context. Curious :)

from gallium.

thanks @ernesto-jimenez

from gallium.