[feature] Make types more discoverable #73

New Issue

ungleich-gitea · 2021-11-20T13:23:30Z

ungleich-gitea commented

2021-11-20 13:23:30 +00:00

Consider adding a cdist find_type ${TERM} command that basically does grep -r "${TERM}" "${CDIST_DIR}/cdist/conf/type" "${USER_CDIST_DIR}/type"

I guess even those well-versed in current cdist types may get lost at times and could use something like this to quickly find what they need.

Consider adding a `cdist find_type ${TERM}` command that basically does `grep -r "${TERM}" "${CDIST_DIR}/cdist/conf/type" "${USER_CDIST_DIR}/type"` I guess even those well-versed in current cdist types may get lost at times and could use something like this to quickly find what they need.

poljakowski was assigned by ungleich-gitea

2021-11-20 13:23:30 +00:00

ungleich-gitea closed this issue

2021-11-20 13:23:31 +00:00

ungleich-gitea commented

2021-11-20 15:34:29 +00:00

closed

ungleich-gitea commented

2021-11-20 15:34:30 +00:00

mentioned in merge request !825

ungleich-gitea commented

2021-11-20 15:34:31 +00:00

One question.

What are the advantages of cdist info over maintained man page cdist-types which contains general info about types?

Yes, there are no local types (custom user types), but info about them could be maintained, well, locally too :)

One question. What are the advantages of `cdist info` over maintained man page `cdist-types` which contains general info about types? Yes, there are no local types (custom user types), but info about them could be maintained, well, locally too :)

ungleich-gitea commented

2021-11-20 15:34:33 +00:00

@ander I realized that after creating MR for this, that it should be written in python.
But then, I wanted to see a reaction :)

And since it shows type info, then it is really a cdist config info so the command should be cdist config info, or?

@ander I realized that after creating MR for this, that it should be written in python. But then, I wanted to see a reaction :) And since it shows type info, then it is really a `cdist config` info so the command should be `cdist config info`, or?

ungleich-gitea commented

2021-11-20 15:34:34 +00:00

This helper tool does not parse cdist configuration files. Configuration
directories should be specifed by command line options and/or CDIST_PATH
environment variable.

that's annoying 😿

also, why shell script? wouldn't it be easier to be implemented in python since all information is there anyway? same thing with dump. no need to re-implement stuff in shell etc.

also. lots of flags. you'll run out of alphabet soon :cartwheel:

I think we are overengineering here. maybe we should re-think which is needed for user vs diehard cdist masochist. average cdist user (and myself) don't really care which types have gencode-remote, which ones have manifest etc. I only want to find answers quickly.

cdist info <glob> and be done with it.

for example cdist info __ will show all types with all information about then. and from there you can go more into detail eg __apt_ etc. give user grep (over paths) and they will do the rest 👼

> This helper tool does not parse cdist configuration files. Configuration > directories should be specifed by command line options and/or CDIST_PATH > environment variable. that's annoying :crying_cat_face: also, why shell script? wouldn't it be easier to be implemented in python since all information is there anyway? same thing with dump. no need to re-implement stuff in shell etc. also. lots of flags. you'll run out of alphabet soon :cartwheel: I think we are overengineering here. maybe we should re-think which is needed for user vs diehard cdist masochist. average cdist user (and myself) don't really care which types have gencode-remote, which ones have manifest etc. I only want to find answers quickly. `cdist info <glob>` and be done with it. for example `cdist info __` will show all types with all information about then. and from there you can go more into detail eg `__apt_` etc. give user grep (over paths) and they will do the rest :angel:

ungleich-gitea commented

2021-11-20 15:34:35 +00:00

mentioned in merge request !824

ungleich-gitea commented

2021-11-20 15:34:37 +00:00

Here is my first attempt for supporting libexec and migrating cdist-dump to libexec: 7dddcb794b.

Here is my first attempt for supporting libexec and migrating cdist-dump to libexec: https://code.ungleich.ch/ungleich-public/cdist/commit/7dddcb794b91645c04ef81f5f9f1761721962ba5.

ungleich-gitea commented

2021-11-20 15:34:38 +00:00

I will add core 'libexec' support for 'libexec' directory under official 'conf' directory.
Here, internal binaries/scripts should be placed.
I will add core support for detecting such binaries/scripts.
These should be named with 'cdist-' prefix.
'cdist-dump' will be migrated into this directory.

What do you think?

I will add core 'libexec' support for 'libexec' directory under official 'conf' directory. Here, internal binaries/scripts should be placed. I will add core support for detecting such binaries/scripts. These should be named with 'cdist-' prefix. 'cdist-dump' will be migrated into this directory. What do you think?

ungleich-gitea commented

2021-11-20 15:34:39 +00:00

cdist info

`cdist info`

ungleich-gitea commented

2021-11-20 15:34:41 +00:00

IMHO it should be either cdist find or if it only works on types it should be namespaced.

e.g.

cdist types list

IMHO it should be either `cdist find` or if it only works on types it should be namespaced. e.g. ``` cdist types list ```

ungleich-gitea commented

2021-11-20 15:34:42 +00:00

@evilham @nico @ander Can you list what cdist list should do, what you expect from it?
Should it be cdist find?

find [TERM]
find -g [TERM] # grep term
find -p [TERM] # parameters
find -m [TERM] # manifest
find -r [TERM] # gencode-remote
find -l [TERM] # gencode-local
find -e [TERM] # explorers
find [-sin] [TERM] # singleton/install/nonparallel
...

What is the information it should provide?

@evilham @nico @ander Can you list what `cdist list` should do, what you expect from it? Should it be `cdist find`? 1. find [TERM] 2. find -g [TERM] # grep term 3. find -p [TERM] # parameters 4. find -m [TERM] # manifest 5. find -r [TERM] # gencode-remote 6. find -l [TERM] # gencode-local 7. find -e [TERM] # explorers 8. find [-sin] [TERM] # singleton/install/nonparallel ... What is the information it should provide?

ungleich-gitea commented

2021-11-20 15:34:43 +00:00

we have cdist inventory list. ls vs list? make ls as alias? 🤷

for the sake of consistency, we should spell out commands and not use abbrs.

we have `cdist inventory list`. ls vs list? make ls as alias? :shrug: for the sake of consistency, we should spell out commands and not use abbrs.

ungleich-gitea commented

2021-11-20 15:34:45 +00:00

Then we can also migrate cdist-dump to cdist dump, as such command.

YES PLEASE

one utility tule rule them all

> Then we can also migrate cdist-dump to cdist dump, as such command. YES PLEASE one utility tule rule them all

ungleich-gitea commented

2021-11-20 15:34:46 +00:00

@nico Should we implement such commands as cdist core shell scripts for which cdist python implementation is a wrapper?
We can write cdist core part that detects core/support commands.
Then new command is just written as an executable inside libexec or similar sub-directory, and cdist core detects it.
Then we can also migrate cdist-dump to cdist dump, as such command.

@nico Should we implement such commands as cdist core shell scripts for which cdist python implementation is a wrapper? We can write cdist core part that detects core/support commands. Then new command is just written as an executable inside libexec or similar sub-directory, and cdist core detects it. Then we can also migrate cdist-dump to `cdist dump`, as such command.

ungleich-gitea commented

2021-11-20 15:34:47 +00:00

@ander I like it. It reminds me of https://www.cdi.st/manual/latest/man1/cdist-dump.html, but this time for conf directories.

@ander I like it. It reminds me of https://www.cdi.st/manual/latest/man1/cdist-dump.html, but this time for `conf` directories.

ungleich-gitea commented

2021-11-20 15:34:49 +00:00

@ander You are basically describing ls and I really like it. Something on the line of

cdist ls --types
cdist ls --all (default?)
cdist ls --manifests

@ander You are basically describing `ls` and I really like it. Something on the line of * `cdist ls --types` * `cdist ls --all` (default?) * `cdist ls --manifests`

ungleich-gitea commented

2021-11-20 15:34:50 +00:00

lets try to be consistent.

Commands:
  {banner,config,install,inventory,preos,shell,trigger}

instead of ls-types, maybe something more generic, which lists all manifests, types and explorers from all the dirs where cdist will look for them: install dir, conf dir and current user home dir.

maybe list, which just prints all available types, explorers and manifests, and list fuzzystring for getting list params for matched types?

for example, most of the time, when i open manual, i want to see parameters list. and the output of cdist list __type should be useable with grepawksed&family so we can create editor integration. magic. for example, output of cdist list fuzzystring:

__matched_type: parameter_type: parameter_name

lets try to be consistent. ``` Commands: {banner,config,install,inventory,preos,shell,trigger} ``` instead of `ls-types`, maybe something more generic, which lists all manifests, types and explorers from all the dirs where cdist will look for them: install dir, conf dir and current user home dir. maybe `list`, which just prints all available types, explorers and manifests, and `list fuzzystring` for getting list params for matched types? for example, most of the time, when i open manual, i want to see parameters list. and the output of `cdist list __type` should be useable with grepawksed&family so we can create editor integration. magic. for example, output of `cdist list fuzzystring`: ``` __matched_type: parameter_type: parameter_name ```

ungleich-gitea commented

2021-11-20 15:34:51 +00:00

I have to say I see some convenience here, especially if -C is given multiple times.

@evilham can you do a prototype on cdist ls-types which accepts standard glob afterwards? I think if the code is cleanly separated (which it should be easily doable), I'm open for adding things that make the user experience nicer.

I mean, in the end cdist is there to make life easier.

I have to say I see some convenience here, especially if -C is given multiple times. @evilham can you do a prototype on `cdist ls-types` which accepts standard glob afterwards? I think if the code is cleanly separated (which it should be easily doable), I'm open for adding things that make the user experience nicer. I mean, in the end cdist is there to make life easier.

ungleich-gitea commented

2021-11-20 15:34:53 +00:00

to get list of available types? just open https://www.cdi.st/manual/latest/cdist-types.html ?

i have this bookmarked. tho, sometimes I need to look at the code for ideas, but then i know where to look 🤷

to get list of available types? just open https://www.cdi.st/manual/latest/cdist-types.html ? i have this bookmarked. tho, sometimes I need to look at the code for ideas, but then i know where to look :shrug:

ungleich-gitea commented

2021-11-20 15:34:54 +00:00

@nico @steven What do you think?

Sign in to join this conversation.