Implementing a shell function library #84
Labels
No Label
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ungleich-public/cdist#84
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue is kind of a follow-up to my merge requests !795, !796, !797, !798.
A seemingly simple change required touching several types and after looking at the BSDs I realised that we're still not quite there, yet (BSDs lines have a different order and length).
Having the same code distributed in various types has many disadvantages and is very time-consuming and error prone to maintain.
To improve on this I thought it would be great to have a library of shell functions contained in cdist which can be used to carry out common tasks.
The library functions could also contain generic functions like string manipulation functions,
not_supported(to make error messages look more alike),presence(to replace all of those[ ... ] && echo present || echo absentsnippets) etc.mentioned in merge request !920
mentioned in issue #827
mentioned in merge request !896
unassigned @poljakowski
Regarding the copying library functions to the remote host, this could be circumvented by implementing a simple preprocessor à la
cpp.I believe shell types won't be removed from cdist, so people will continue writing types in shell.
@steven @ssrq Regarding lib, I am still not sure, to have lib, or not to have lib.
I agree that remote code (explorers and code-remote) should be flat, where most, if not all, the logic is done by the manifest and gencode script - that's why there are explorers, to inspect remote system, and depending on remote state to generate simple code that is then executed on the remote.
So we should not require remote lib.
@ssrq Regarding python types, you can look at https://code.ungleich.ch/ungleich-public/cdist/tree/beta branch, and beta docs, https://www.cdi.st/manual/beta/cdist-type.html#python-types.
Yes
Ah, then I'm relieved. The main reason for me to use cdist is that I can use it to configure devices which will never be capable of running Python.
So eventually manifests and gencode-* scripts can be written in Python, but explorers and the "code" stays POSIX shell?
No. Target hosts requirements will always stay minimal.
We (Darko) has been experimenting rewriting some of the types in Python.
In the last release the __file type is coded in python.
Moving types to Python?
Does this mean that in the future Python will be required to be installed on all target hosts?
@steven The reason for having a remove lib is for explorers.
While the
gencode-*scripts usually do one specific job, they need information from explorers.Some pieces of information are needed by different types (cf. the MRs mentioned in the OP or all of the PostgreSQL types, see my old OpenBSD MRs).
So you start to copy the
cases over from another type, which then gets patched by other people for other situations.Eventually, you end up with many different
messesimplementations to get the same piece of information.As in cdist types cannot be nested (I asked for such a feature some time ago) or there is a way to share code between types, having a (local and remote) lib is the most trivial way to solve this problem.
While I see the potential value of such a lib.sh library, aren't we in the progress of moving types to python? Are we feeding a dead animal by starting this lib.sh now?
I think I'm -1 on having a remote lib. Don't see the point/use case.
The generated code should be as simple/stupid as possible. All heavy lifting should be done in the gencode-* scripts. If you think you need a remote lib you're probably doing to much in your generated code.
I don't think there's enough of them to split them into different files.
IMHO just have one lib.sh
Not sure I like the double underscore prefix. Makes it look like a type which it is not.
Yes, if we will add support for remote shell lib, then we should separate local and remote lib.
I include our BDFLs :) @nico and @steven. What are your thoughts on this?
@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.
getentor anything that pulls information out of the OS should never be run locally.Moreover, local functions might want to leverage
python3.Functions which can be used on both sides (like
error.sh) could be linked fromrlibintolib.What do you think?
@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?