kube refine for backup

[fj0r]

• new function kube refine

  • define the required information in $env.KUBERNETES_REFINE, kube refine will collect information according to its definition
  • definitions in status and cluster_status are runtime information and will not be collected. They are used in the kg command to display status
  • normalize the output of the kg, kgp, kgs command using krefine

• rename kcconf to kccc (kubectl change context clone)

• a new module, refine.nu, declaratively extracts data from complex structures.

• container-list additionally displays the cmd field of the image

[fdncred]

I'm not a fan of these changes. It's hard to tell what this argx file you're putting in several folders does. There are changes not mentioned in the description. You're creating a new log command when there's already one in the std lib. Lack of comments explaining what the custom commands do.

[fj0r]

The argx file is copied from modules/argx/argx.nu for the purpose of passing the ci test.I'm not sure if the CI test must be passed, and I don't know of any other better methods.

Log command can support structured logs in logfmt (not strict), and can output to a file (I'm not sure if std log can).
It has four parts:

• time
• level
• all the records in the arguments are merged together as the logfmt part,
• all strings are merged together as the plaintext part

The latter two are optional.
If called with log level <num>, the level name can be hidden, which is suitable for scenarios where you only want to distinguish by color.
There is also an additional trace level, level names are unified into three characters to keep them neat. Because inf literal are recognized as number, an additional synonym msg is added.
Use │(U+2502) instead of │(pipe) as the delimiter because the message may contain │(pipe) and │(U+2502) is easier to parse.
For me, the most important thing is carefully adjusted output, finer highlights(apply color only on datetime to improve readability), soft colors, and better ergonomics.
In my opinion, custom colors and formatting are not that important because they are not easy enough to take a few minutes to do. It may be easier to support customization. In practice, it is important to provide a good set of default configurations

This part was originally written directly as a function in kubernetes.nu. Later, there were too many references, so it was taken out as a separate module. If I follow the original method, I need to copy the kubernetes.nu file and then paste this section, which is too troublesome. I can also remove the part kube refine that refers to it, but then I need to delete this section every time I update it.

[fdncred]

Your changes are better but I'm still not a fan of log. I'd prefer it be a different name so it doesn't stomp on our log in std-lib.

[fj0r]

ok, I understand, how about changing it to slog or lg?

update: has been changed to lg

[fdncred]

ok, good enough. do you want to keep working on it or are you done?

[fj0r]

88be461
I renamed some modules and it feels good (sorry, just found out about mod.nu)
But in this case, the user needs to make some adjustments. I don’t know if this is appropriate.

[fj0r]

https://github.com/nushell/nu_scripts/actions/runs/8488088746/job/23256669801
There is no problem with this directory structure in my local machine. I don’t know why ci panic again.

[fj0r]

If this ok, please merge it. Otherwise, I will revert 88be461 .

[fdncred]

The only thing that bothers me is that you renamed git-v2.nu to mod.nu as if your git module owns the changes in that folder. It may be better to make a gitv2 folder to switch to mod.nu so the other files don't get lost.

[fj0r]

Ok, but the file git/README.md also belongs to gitv2, and I moved it there too.