Let new projects not carry the dependency burden of amber CLI

[hugopl]

Description

Amber have a lot of dependencies, this wouldn't be so bad if the projects that depends on it wouldn't need to carry this dependency burden, like always depend on sqlite3, mysql and postgres.

If I didn't misunderstood anything, amber CLI is meant to be installed in the system, e.g. there's a ArchLinux amber package on AUR.

Steps to Reproduce

1. Run amber new foo then shards install

Expected behavior: [What you expect to happen]

I would expect the first shards install to depend only on things that my project needs to be compiled, not everything that is needed to compile a new amber CLI.

Actual behavior: [What actually happens]

The new project will depend on everything that amber CLI depends to be built.

Reproduces how often: [What percentage of the time does it reproduce?]

100%

Versions

Crystal 1.14, amber 4088e62, shards 0.18.

[hugopl]

I have some ideas on how to fix that.

• Let the amber shard hold just the amber CLI.
• Create a amberframework/framework shard, shard.yml files created by amber CLI would depend on it instead of amber shard.

How want to have the old behavior, or just like to build their own amber CLI would just depend on both shards, amberframework/amber and amberframework/framework.

[crimson-knight]

@hugopl I complete agree with you. My slowness to make changes here is due to a couple of things:

1. The current CLI tool has features that were unclear if others were using, such as recipes.
2. The CLI and application template are very tightly coupled, which has made it painful to split.
3. With AI moving forward at a stead and rapid pace, I want to make improvements in the direction that the workflow for application development is moving. For example, instead of generators, can we have an AI agent follow a set of instructions to configure our application?

I made a proof of concept for replacing the amber new <app name> part of the generator, and this application is configured to use Jennifer instead of Granite.
Here is a screen cast showing my single prompt, and then the agent (using Cursor) goes to work to configure the application and starts it for me https://youtube.com/shorts/gMG9RMEv6Ik

Here's the framework template I was basing it off of: https://github.com/crimson-knight/agentic-development-template

My thought is:

1. Instead of a CLI tool that generates the application template, it can be cloned or forked from, and versioned separately from the framework dependencies. This decouples the CLI and the framework.
2. The docs are provided within the app template, and they can be customized as your application grows. We all add patterns that we like, and this lets you customize (or create) your own "generator" instructions that a model can follow. You can grow your agents capabilities along with your app. That's pretty awesome, and I've wanted this for a long time.
3. No more CLI dependencies as part of the framework.

I still plan to focus on this more in depth after Christmas going into the new year. I have vacation coming up starting the 21st through the new year so I'll be able to focus on this and release an update for the new year.

[hugopl]

I like the idea of an application template, but the CLI would still be needed for things like: create migrations, scaffolding, controllers, etc.

On unclear CLI features, I can nominate "recipes".

But would be nice if no CLI would be necessary.. or if it didn't had a lot of dependencies.

[crimson-knight]

@hugopl I have the initial migration of the CLI out of this repo into https://github.com/amberframework/amber_cli

This was a very significant move, almost everything was moved.

Almost everything is important.

It drops recipes because that was using the outdated version of liquid.cr and was very tightly coupled with old CLI behavior.

Although this feature was complete, as long as I've been involved with Amber it has been unused. So instead of spending time to upgrade it, I removed it and instead began the initial implementation of configurable generators.

Reduced third-party dependencies. A more complete list:

• liquid.cr
• cli
• shell-table
• inflector
• teeplate
• yaml_mapping
• json_mapping

I still have to add more test coverage and do some manual checking to ensure it does everything as originally planned. Big step forward though!

[hugopl]

It's sad, but I'm now using Kemal with some code to be able to use Controller classes, so my interest in Amber isn't so great right now.

But as good (vapor) news at web side of crystal. I plan get the slang gem and let it work with Liquid template expressions, so will be possible to render slang templates at compile or run time.

I also ported the slim tree-sitter to slang https://github.com/hugopl/tree-sitter-slangtemplate