libelektra
libelektra copied to clipboard
Kdb rewrite base
This is the "framework" for the new C cli.
I'll mention PRs for commands later here.
This can be merged as is, more commands can be added later.
- ~add spec support for external commands~: #4951 (reviewed and now in
kdb_rewrite_base) - ~add spec for
C++commands~: #4949 (reviewed and now inkdb_rewrite_base) - ~add set command~: #4954 (reviewed and now in
kdb_rewrite_base) - add meta commands: #4955
- this one
Basics
- [ ] Short descriptions of your changes are in the release notes
(added as entry in
doc/news/_preparation_next_release.mdwhich contains_(my name)_) Please always add them to the release notes. - [ ] Details of what you changed are in commit messages
(first line should have
module: short statementsyntax) - [ ] References to issues, e.g.
close #X, are in the commit messages. - [ ] The buildservers are happy. If not, fix in this order:
- add a line in
doc/news/_preparation_next_release.md - reformat the code with
scripts/dev/reformat-all - make all unit tests pass
- fix all memleaks
- fix the CI itself (or rebase if already fixed)
- add a line in
- [ ] The PR is rebased with current master.
Checklist
- [ ] I added unit tests for my code
- [ ] I fully described what my PR does in the documentation (not in the PR description)
- [ ] I fixed all affected documentation (see Documentation Guidelines)
- [ ] I fixed all affected decisions (see Decision Process)
- [ ] I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
- [ ] I updated all meta data (e.g. README.md of plugins and METADATA.ini)
- [ ] I mentioned every code not directly written by me in reuse syntax
Review
- [ ] Documentation is introductory, concise, good to read and describes everything what the PR does
- [ ] Examples are well chosen and understandable
- [ ] Code is conforming to our Coding Guidelines
- [ ] APIs are conforming to our Design Guidelines
- [ ] Code is consistent to our Design Decisions
Labels
- [ ] Add the "work in progress" label if you do not want the PR to be reviewed yet.
- [ ] Add the "ready to merge" label if everything is done and no further pushes are planned by you.
Thanks a lot for the feedback!
jenkins build libelektra please
jenkins build libelektra please
Also important is to explain all differences in the release notes, e.g.:
kdb get
Sorry, I could not process the arguments: Need one argument
Usage: kdb get <name>
Get the value of an individual key.
When the key starts with / a cascading lookup will be done.
Example:
kdb get system:/elektra/version/constants/KDB_VERSION
-a --all Consider all of the keys.
-d --debug Give debug information or ask debug questions (in interactive mode).
-H --help Show the man page.
-n --no-newline Suppress the newline at the end of the output.
-p --profile <name> Use a different profile for kdb configuration.
-v --verbose Explain what is happening.
-V --version Print version info.
-C --color <when> Print never/auto(default)/always colored output.
vs. (in the new version)
kdb get
ERROR: Expected at least 1 non-option arguments, but only got 0
shouldn't come as surprise for the user.
Thanks for the review! The compare should work now, I mostly used commit --fixup=, should I have also pushed the !fixup commits? I felt like that would be weird in the git history.
jenkins build libelektra please
jenkins build libelektra please
jenkins build libelektra please
Thanks for the feedback!
Thanks a lot for the feedback @markus2330 !
I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new PR with the remainder of this PR. Thank you for your contributions :sparkling_heart:
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new PR with the remainder of this PR. Thank you for your contributions :sparkling_heart: