kedgeproject
Output generated by `kedge init` is human unfriendly :-(
The file generated by kedge init is not friendly for new users :-(
./kedge init -c DeploymentConfig -i tomaskral/nonroot-nginx -p 8080 --name demo
currently, it looks like this
containers:
- image: tomaskral/nonroot-nginx
controller: DeploymentConfig
name: demo
services:
- portMappings:
- 8080
But something like this would look much better.
name: demo
controller: DeploymentConfig
containers:
- image: tomaskral/nonroot-nginx
services:
- portMappings:
- "8080"
this is much easier to read and more importantly edit
ping @pradeepto
@kadel Does make sense to me but my first and only thought was - "will it make users think that vertical space is mandatory?"
@kadel Does make sense to me but my first and only thought was - "will it make users think that vertical space is mandatory?"
I don't think that. But if that is a concern, we can remove those empty lines. For me personally, it creates nice logical blocks, but it just something that I like to do. I don't have a strong opinion about that.
I'm convinced that ordering is important, it doesn't change anything, but it is much more logical.
@kadel so we are marshalling this struct App so we don't control order of the fields marshalling, the library takes care of doing that. Inside struct I have defined the fields in the order you have mentioned.
@kadel so we are marshalling this struct App so we don't control order of the fields marshalling, the library takes care of doing that. Inside struct I have defined the fields in the order you have mentioned.
But the important is how it looks like in the output file.
The way we have implemented this is maybe making it a bit easier for us, but it definitely makes it harder for new users and first-time kedge users. I don't think that this is a good tradeoff @pradeepto
To maintain the sequence what we can do is that we define multiple structs:
type Name struct {
Name string
}
type Controller struct {
Controller string
}
type Containers struct {
Containers []Container
}
type Services struct {
Services []Service
}
Now we define objects of each and define value as needed, now marshal each struct object into yaml and now keep those marshalled bytes, keep marshalling each struct object and appending up bytes, as we need keep adding empty lines or instructions in bytes.
So basically carefully craft the file. This might seem overkill and you might as well suggest why not go back to golang templating, but I don't have an answer for that.
I still don't see what is the benefit of approach compare to templating.
It would make sense if we could use types from type.go. But without that, I don't see any benefit of doing it like this.
@kadel we are not using structs from types.go because
https://github.com/kedgeproject/kedge/blob/0f5093e8c6fbca005082a79cdaf0a60bbc41ada7/cmd/init.go#L34-L45
@kadel we are not using structs from types.go because
yes I know. What is a benefit of using separate structs over templating new file? There are still two different places where the structure of the file is kept.
@kadel templating will allow us to add blank lines, so that output will look better and more readable
