patrickdappollonio / kubectl-slice

Split multiple Kubernetes files into smaller files with ease. Split multi-YAML files into individual files.
MIT License
289 stars 21 forks source link

Suggestion: Use input file as a default argument #94

Closed 13sh closed 6 months ago

13sh commented 1 year ago

Thanks for the tool, today I faced the same issue that it tries to solve, and after a while of trying to get it done using yq I tried kubectl-slice and it worked exactly like I wanted from first try.

I have a suggestion that I thought it would make even more convenient: Allow inputFile as an argument in addition to the flag, and use . as a default output, the usage I imagine is something like this: kubectl-slice templates.yaml

patrickdappollonio commented 1 year ago

Hey @13sh!

Seems like a good idea. My main concern for it is that a) it would be a breaking change for current people running it in automation (the . being defaulted, that is); and b) I feel the difference between a single-flag argument versus a positional is that the single-flag is clear that only one yaml file can be processed at a time.

For the 2nd, it would naively be my assumption that if I see this in the wild, I could do:

kubectl slice templates.yaml templates2.yaml

And then slice would merge them into one before processing. Lots of rules would have to be decided (for example, priority order). Today though, while passing the -f argument more than once is possible, it follows the standard of "last argument wins". In the positional one, this might not be the case, and there are potential issues if we would choose to go to merging them. The other part is that we keep the shorthand as a helpful reminder for people using it as a kubectl plugin since -f is widely used by kubectl (although granted, kubectl does support passing more than one file with -f).

If you don't mind, I'll like to keep this issue open for the time being to gather data from users and people (I'll ask around).

Thanks a lot for the suggestion!

13sh commented 1 year ago

You can keep the flag arguments and give them higher priority:

 kubectl-slice --input-file=input.yaml --output-dir=. templates.yaml 

would ignore the positional argument and go with input.yaml

13sh commented 1 year ago

piggybacking: since a lot of people who would use this tool will have go installed on their machine, you can add that to the install part of readme, that is how I installed it:

go install github.com/patrickdappollonio/kubectl-slice@latest  
patrickdappollonio commented 1 year ago

Let's leave it open for some people to chime in if possible.

For the latter, bold of you to assume Go devs are the most downloads 😆 most of the open source usage comes from CI which while it might have Go installed, they often just pull the binary directly from the downloads (and that shows by the download counter). For that in particular I'm doing 2 things:

  1. A bash script to download the app
  2. An updated readme

I'll strip these two thoughts into another issue. For Github, it's better not to piggyback 😅 otherwise things get forgotten when the main situation gets resolved haha.

cbmdfc commented 1 year ago

i preferr declarative approach over passing it like this bc i know i am doing by reading the command

i prefer to keep it the way it is

patrickdappollonio commented 6 months ago

Hey @13sh!

So I asked around (and we can see @cbmdfc's comment up top as well) and I'm inclined to not add this, unfortunately.

The reasons are many but after talking to some more knowledgeable people than I am, it was clear that positional arguments really don't have a standardized way of being used: some CLIs will take the first parameter and ignore the rest, while others would do what you were suggesting around prioritization.

I think @cbmdfc mentions what I heard as well: providing your file with --input-file or -f makes the process clear in intention. It also describes that you cannot pass more than one file, while the positional won't have that "prior experience" that other CLIs might have because, depending on your background, the positional might mean so many different things and hint at even more meanings.

Appreciate the willingness to open the issue though! Please don't hesitate to open a new one if you would like to see a new feature built into the app.