CLI

[NWBY]

Big Laravel fan here and have just discovered Confetti and really liking it so far.

I’m wondering if there are any plans to implement a CLI tool similar to Artisan to generate new Models, Migrations, etc.

Happy to discuss, plans and contribute to this if needed.

[reindert-vetter]

I have decided to focus on a CLI tool. Maybe you can help me come up with a name. See also: https://www.reddit.com/r/laravel/comments/lhg31y/do_you_know_a_name_for_a_cli_tool_for_confetti_go/

[reindert-vetter]

Actually, I would like to omit 'go run' 🙈

[Wulfheart]

Why? This would allow to add commands dynamically.

[marcelloh]

but you need to program those "dynamic" commands too, so there's nothing dynamic about it.

[marcelloh]

Clifetti?

[reindert-vetter]

Why? This would allow to add commands dynamically.

But of course. See another message in this discussion.

[reindert-vetter]

Working hard to make an Artisan alternative to Confetti. A preview:

[reindert-vetter]

@bosix The first version has been made. It now only works for boolean flags. In addition, I have not yet completely gone through and polished my code.

confetti
foundation
contract

I'd love to hear if you have any feedback. I will also add you as a reviewer when I open my pull request.

[bosix]

@reindert-vetter thank you for sharing. This looks very nice.

Here are a few things I want to mention:

I think the way flags are parsed into the command struct could be done easier. You already use reflection to detect the name of the flag and flagset to handle the flags but I think if we can prevent creating []ParsedOption (GetOptions() in option.go) and some of the other boilerplating:

package main

import (
	"flag"
	"fmt"
	"reflect"
)

type MyCommand struct {
	StringFlag string `short:"f" long:"flag" description:"this is how to use the command"`
}

func main() {
	cmd := reflect.TypeOf(MyCommand{})
        // I skip iterating over all fields to make the example easiert to read
	field := cmd.Field(0)
	shortName := field.Tag.Get("short")
	description := field.Tag.Get("description")

	myCmd := MyCommand{}

	switch field.Type.Kind() {
	case reflect.String:
		flag.StringVar(&myCmd.StringFlag, shortName, "", description)
	case reflect.Bool:
		//flag.BoolVar(&myCmd.StringFlag, shortName, false, description)
		panic("proper implementation needed")
	}

	flag.Parse()

	fmt.Printf("%+v", myCmd)
}

Even if you don't want to parse the value directly into the command you could use struct flag.String() which returns a pointer to the actual parsed value which can be used afterward.
I also like that error handling and help output are already done within the flag package and we do not need any parsing since the default pattern and parsing of golang is used (I saw that your implementation works well with -f hello but not with -f=hello)

The default/fallback value could also be set via reflection or inside the kernel when the command is registered.

It would be a pleasure to review the code when it's done. This may take some time since I'll move to a new apartment in the next few days and I don't know how much time I'll have to review.

[reindert-vetter]

I think if we can prevent creating []ParsedOption (GetOptions() in option.go)

Thanks for your feedback. I looked at another one and the parsing data from the struct is used in 2 places: When registering the flags and setting the values. I thought it was nice to collect the data from a struct. But I'll investigate this further tomorrow. Feel free to try the code and see if you can make it more beautiful!

first example

Thanks for your example. In your example you have a switch case for each type. The problem with that, however, is that if someone defines a custom type in a field (for example [] model.User) it is not easy to modify.

I also like that error handling and help output are already done within the flag package

You are absolutely right. Thanks for your tip. I now use that in an example Getter https://github.com/confetti-framework/confetti/pull/120/files#diff-78dcb0b45b05161a9dacddf241a5ff995ef1ad290407711d4ea77fe291d37dbaR22. The error looks really good!

I saw that your implementation works well with -f hello but not with -f=hello

Fixed. It now works with all types offered by golang itself. In addition, I made 2 examples so that people can use them as an example for self-made flag.Getter.

The default/fallback value could also be set via reflection or inside the kernel when the command is registered.

Indeed. I still find this difficult because I would not expect it when registering. How do you feel about defining that in the field tag? For example Username string flag:"username" default:"bosix"`?

New apartment

🏠 Congratulations on your new apartment! 🎊 I hope your move is going well. Take your time!

I will add extra functionalities in the meantime.

PR:
#120
confetti-framework/foundation#13

[bosix]

Just a few thoughts without looking too deep in the new version of the source code:

Thanks for your example. In your example you have a switch case for each type. The problem with that, however, is that if someone defines a custom type in a field (for example [] model.User) it is not easy to modify.

Do you think that it's necessary to allow custom/complex types for command params? I was just thinking about how a user struct would be passed via cli: maybe as json go run main.go process:user "{\"name\":\"john\"}". In my opinion, we shouldn't allow this. We could, if necessary, use reflect.Slice and reflect.Struct together with some fancy parsing to process such params but I don't think that there is any use-case for this. Any kind of switch is needed anyway since at someplace we need to decide which target datatype the input should be converted into.

How do you feel about defining that in the field tag?

Sounds great. We should be careful not to make too much stuff with reflections and tags since the more we do with this the more can go wrong at runtime and the better all tests must be written. Maybe we could suggest the developer the "New"-pattern of go when initializing a struct:

func NewMyCommand() MyCommand {
	return MyCommand{
		StringFlag: "test",
	}
}

The kernel would then call the function instead of creating an empty command struct.

I'll have a look at the new changes you made hopefully later this week and maybe I'll also have some time to add some more code examples or suggestions on how to improve your code.

[reindert-vetter]

custom/complex types for command params - it's necessary

I had the idea to pass user ids to the command. I would often use it to turn on feature flags. But you are actually right that we should not encourage complex types. If we document this, it should be at the bottom of the page.

default values

You're right we shouldn't use more reflections. We can also choose not to implement the default values. Although I don't want to use generics too much, but this can be a nice use case to be able to register both a struct and a new function.

Thanks for your feedback! You are really right that we should not use too much magic.

[reindert-vetter]

See #121

[reindert-vetter]

Today I've been working on the usage message of a command.

Before (default Go):

After:

Do you think we should stick to the standards? https://clig.dev/#help

[KinyaElGrande]

Yes i think we should stick to the Standards.

[bosix]

I'll have to say that I like both versions. The first one because it's the default of go and the second one because it also shows the required data types (int, string, etc.).

I think the decision depends a bit on the effort needed to implement the second version properly.

[reindert-vetter]

@bosix @KinyaElGrande @Wulfheart @NWBY
I have to do some extra testing and I have to check the documentation, but everything should work. Feel free to take a look:
https://www.confetti-framework.com/docs/digging-deeper/commands

https://github.com/confetti-framework/confetti/releases/tag/v0.20.0

[reindert-vetter]

Looking good! That does not look that difficult indeed. If you make a few tests, you can create a pull request. Otherwise, I will implement this next week.

[bosix]

I can also provide some tests for the code and I'm already on it. My only problem is that I've no idea how to test the confirmation. I tried to write to kernel.Writer but this does not work.

[reindert-vetter]

I will make situations with a Stdin more accessible for testing. Maybe I'll get it done tonight, otherwise tomorrow.

[reindert-vetter]

I was able to fix it in github.com/confetti-framework/foundation v0.5.9. From test/console/output_test.go:124 you will see a number of tests. You can use those tests for inspiration. Don't forget to add a newline when specifying the writer.

You can define the writer using NewCliByReadersAndWriter(). Bit of a long name for a constructor, but I also thought it is a bit overkill to use callbacks options for this.

Of course, feedback is welcome!

[bosix]

Well, the name is a bit clunky but the function just works like a charm. I've finished the tests and I've seen that you are already on the pr :)

[reindert-vetter]

@bosix @KinyaElGrande @Wulfheart @NWBY
🥳 After hard work, the time has come: https://www.confetti-framework.com/docs/digging-deeper/commands

I also made a separate template for it. This allows you to use Confetti Commands if you just need to create a CLI tool:
https://github.com/confetti-framework/commands

[KinyaElGrande]

May I say I like the way that you have implemented it . Then everything just flows and the documentation to me is too informative I love it.

[reindert-vetter]

Thanks @KinyaElGrande!

Do you use something of Confetti at work? I'd love to hear what you're missing.

[KinyaElGrande]

Nop, currently I just use it with my personal side project.
I don't have a job at the moment but in my previous Jobs, I used laravel a lot and I love Go .

I haven't found proper time to look at Confetti been finishing up with my school this is the last month yeii . Soo from April I'll be free and I am going to interact with Confetti more and more , if something comes up I'll be raising it for sure.