@ander How about adding new options and documenting old ones as present for backward compatibility? Or does this require additional complexity in type implementation?
If it benefits most of our users
yes, it will benefit all 3 users! 😈
I added compatiblity for old parameters, but now we still have open question how do display warning only if…
@ander yes, I meant on something like deprecated file containing list of deprecated params. First I meant to include such file for each param with message for each deprecated param, but one file with…
Details should go into man page anyway, righy?
yes. just like I updated man for __acl
@nico @steven Can you review current state of python types support?
One thing that is pending and it…
changed title from Implement core support for python types to {+beta branch: +}Implement core support for python types
@nico @steven d751bad039 adds python type defined argument parser support. I know that current implementation is…
"we" have init manifest per host, which has all the calls to types for configuring dns, setting timezone and... heh... disabling ipv6 :) etc.
i find this way more explicit and manifest is then kind…
Examples to be implemented:
- cdist task create-django-hosting --name aname --project-name customersupplied
- cdist task create-vpn --public-key
- cdist task create-glarnercloud…
@nico If we are going to support shell lib functions in explorers (and possibly code-remote) then lib files should be transferred to remote, like parameter files are transferred. What do you think?
@poljakowski Thinking about this point maybe we should distinguish between local lib and remote lib?
I can imagine functions which only make sense on either the local or the remote host. E.g.…