v2 CLI

[paganotoni]

This PR changes the approach we've been taking on the CLI aiming to provide the ability to plugin custom commands to the Buffalo CLI, at a higher level this would compact the stack that will be supported by the Buffalo team and allow Buffalo developers to write plugins that solve their workflow specific needs.

In terms of the ability to override the CLI there are 2 main needs:

• Allowing to add plugins on a Buffalo codebase
• Allowing the use of custom plugins to generate Buffalo applications

These two capacities are vital to improving the out-of-the-box experience for Buffalo by allowing developers to provide support for their own tools and let the Buffalo maintainers focus on a better experience for the frontend stack.

Also, Some of the resulting effects of this new shape of the Buffalo CLI are:

• Reducing third-party dependencies (using more of the standard lib)
• Cleaning up old issues
• Improving the maintainability of the Buffalo CLI.

In order to achieve those 2 overall goals we should complete the following steps:

• replace help instructions
• convert base commands to plugins
• rewrite pop plugin
• add plugins command (to list plugins)
• implement plugin override API (remove, add, clear)
• implement custom CLI main feature (in cmd/buffalo)
• implement global per-user default plugins (in $HOME/.buffalo/cmd).

[paganotoni]

@sio4 One thought I've been having is the following. the CLI is v0 and v0 means (AFAIK) that it's rapidly changing and there are no API guarantees. Which I think is the reason most people want to see Buffalo hit v1.

I wonder if we're being too careful with Buffalo CLI and Library when implementing changes, what do you think?

[sio4]

One thought I've been having is the following. the CLI is v0 and v0 means (AFAIK) that it's rapidly changing and there are no API guarantees. Which I think is the reason most people want to see Buffalo hit v1.

Yes, I agree that people want to see v1 since they want to use "stable" tools and libraries for their projects.

This is the reason I want to mark the current version of the buffalo core library (https://github.com/gobuffalo/buffalo) as v1 so the users can use the current version on their production with the belief of the version will last be stable even though the buffalo grow further. When the developers use v0, they could be more careful and will have concerns about possible breaking changes. Meanwhile, I believe the current version is already ready for production, and making it v1 will help both the users to use it in production and us to develop the next version with no strong concern about breaking changes.

For the CLI, I think it was slightly different from the library since it is a tool, not a library which could affect the user's application. It only will affect the development process and pipeline (along with CI/CD) so we should treat them with a separated versioning approach. I think the legacy CLI is also saturated enough as a production tool, so I hope we can make the current version v1 and develop the new architecture on the main branch.

One more consideration for the CLI is that previously the CLI module does not expose any method or something, so the version scheme is relatively free and in fact, the version number does not need to be semantic. However, with your new architecture, the CLI became an importable module to extend the feature so it should have a meaningful version with a semantic scheme.

I wonder if we're being too careful with Buffalo CLI and Library when implementing changes, what do you think?

So my idea/conclusion is that:

• make the current/legacy version of CLI v1 (in the v1 branch) so we can keep the support of the version until its EOL.
• move the new architecture development into the main and start releasing v2-preview versions so early bird users can start using the new version of the buffalo CLI and make it feasible soon.
• also make the current version of the core library v1 (in the v1 branch) so we keep it stable and we can support it.
• make the main branch of the library a branch for the new version and start to improve the library with breaking changes if needed.

What do you think? your approach and mine are different on two points.

• your recent branch change kept the legacy on the main and the new version on the v1 branch, but my idea is we need to legacies on the versioned branches (v1 for now, next to v2,...) and the main will be always for the new one.
• it seems like you want to keep the current version as v0 but I want to make them v1. Actually, there is no v0 in the golang module (v0 and v1 may have the same import path, v0 is just a conceptural version before v1)

If you agree with my direction, I will work on it this week.

[paganotoni]

This is the reason I want to mark the current version of the buffalo core library (https://github.com/gobuffalo/buffalo) as v1 so the users can use the current version on their production with the belief of the version will last be stable even though the buffalo grow further. When the developers use v0, they could be more careful and will have concerns about possible breaking changes. Meanwhile, I believe the current version is already ready for production, and making it v1 will help both the users to use it in production and us to develop the next version with no strong concern about breaking changes.

Yes. I think we should do that.

[paganotoni]

So my idea/conclusion is that:

• make the current/legacy version of CLI v1 (in the v1 branch) so we can keep the support of the version until its EOL.
• move the new architecture development into the main and start releasing v2-preview versions so early bird users can start using the new version of the buffalo CLI and make it feasible soon.
• also make the current version of the core library v1 (in the v1 branch) so we keep it stable and we can support it.
• make the main branch of the library a branch for the new version and start to improve the library with breaking changes if needed.

What do you think? your approach and mine are different on two points.

• your recent branch change kept the legacy on the main and the new version on the v1 branch, but my idea is we need to legacies on the versioned branches (v1 for now, next to v2,...) and the main will be always for the new one.
• it seems like you want to keep the current version as v0 but I want to make them v1. Actually, there is no v0 in the golang module (v0 and v1 may have the same import path, v0 is just a conceptural version before v1)

@sio4 What if we just throw away the old-version of the CLI? Taking into consideration that v0 provides no-guarantees we could just use this PR as the base. Assuming except for the plugins the behavior is the same we should be able to keep going with v1.

After all, plugins are an advanced feature of the CLI. Right?

[sio4]

This is the reason I want to mark the current version of the buffalo core library (https://github.com/gobuffalo/buffalo) as v1 so the users can use the current version on their production with the belief of the version will last be stable even though the buffalo grow further. When the developers use v0, they could be more careful and will have concerns about possible breaking changes. Meanwhile, I believe the current version is already ready for production, and making it v1 will help both the users to use it in production and us to develop the next version with no strong concern about breaking changes.

Yes. I think we should do that.

OK, then I will work on it (the core library versioning) this week. (actually, I am more passionate about the library part :-)

[sio4]

So my idea/conclusion is that:

• make the current/legacy version of CLI v1 (in the v1 branch) so we can keep the support of the version until its EOL.
• move the new architecture development into the main and start releasing v2-preview versions so early bird users can start using the new version of the buffalo CLI and make it feasible soon.
• also make the current version of the core library v1 (in the v1 branch) so we keep it stable and we can support it.
• make the main branch of the library a branch for the new version and start to improve the library with breaking changes if needed.

What do you think? your approach and mine are different on two points.

• your recent branch change kept the legacy on the main and the new version on the v1 branch, but my idea is we need to legacies on the versioned branches (v1 for now, next to v2,...) and the main will be always for the new one.
• it seems like you want to keep the current version as v0 but I want to make them v1. Actually, there is no v0 in the golang module (v0 and v1 may have the same import path, v0 is just a conceptural version before v1)

@sio4 What if we just throw away the old-version of the CLI? Taking into consideration that v0 provides no-guarantees we could just use this PR as the base. Assuming except for the plugins the behavior is the same we should be able to keep going with v1.

There are some background ideas of my thought:

• I don't remember exactly but I am a buffalo user from 2017 or 2016, at least 5 years ago. 5 years is not a short time, the buffalo became stable enough, and I guess many users would not think of the current version as experimental even though they a looking forward to see v1.
• actually, the semantic versioning of go module is relatively a very new thing, the version of buffalo core and CLI was not originally based on the concept. so I think version number 0.18.0 does not mean experimental before v1.
• even though the buffalo CLI is stable enough, there are some bugs or things to be improved for existing users. --> it should be maintained until the new version became stable and officially replace the legacy.

So I hope we can keep the legacy version as v1 until the new version v2 comes. If this is a web service, it may not be a concern but the buffalo is a package software.

After all, plugins are an advanced feature of the CLI. Right?

(I am not fully sure I understand your meaning. Sorry for my bad English) I think it depends. Plugins can be an advanced/additional feature and may not be used frequently except pop. If we just merge the functions of pop or implement it stable, I think we can maybe release the new version even if the plugin support is not fully stable. However, it could be a going back to the early stage of the buffalo without plugins. Not sure how many users use them but buffalo-auth, buffalo-goth are also nice plugins and they help buffalo users a lot.

I think the direction of the new version itself is about plugin support. and I guess it will need more time to get ready with a stable version. I hope we keep the trust of the users during the period too.

[paganotoni]

Hey @sio4, Thanks for being patient with my reply. Things have been very busy for me.
I'm fine following your advice on moving this to be the main branch. as well as treating this as v2 for our users. I will move this to the v2 branch while we get it to main.

[paganotoni]

Moving to v2 Branch until it hits main.