-
-
Notifications
You must be signed in to change notification settings - Fork 2k
refactor: setup CLI open-dkim
#4375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I'd rather not have this in v15.0.0. I marked it appropriately. |
|
I'll take a look at this soon |
casperklein
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code reviewed, but not tested. LGTM 👍
Co-authored-by: Casper <[email protected]>
|
Reminder: Do not merge yet, we still want to release Bundled in the
I have done it in this PR since we usually discuss delaying to a future PR but we often don't get back to it 😅 (likely forgotten) |
test/helper/setup.bash
Outdated
| function __initialize_variables() { | ||
| function __check_if_set() { | ||
| if [[ ${!1+set} != 'set' ]]; then | ||
| if [[ -z ${1:-} ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| if [[ -z ${1:-} ]]; then | |
| if [[ -z ${!1:-} ]]; then |
Without the exclamation mark, you just check, if $1 is not empty.
${!1} is indirect expansion, meaning it retrieves the value of the variable whose name is stored in $1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the sorta thing that adds friction to attracting more third-party contributions though I think? 🤔
Or it encourage people, to learn something new (in bash). I learned a lot while working on DMS 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I learned plenty too, but given the syntax ! / :-, they're not exactly search friendly for a newbie that doesn't know what related keywords to search up.
If we were to swap bash for something else, you've previously expressed reluctance due to the fact you'd have to learn something new... so I don't think that's a particular fair stance 😝
The nushell examples I've shared several snippets of across various discussions is often far more friendly/familiar (or obvious in syntax alone) with equivalent features.
The more friction there is to contribute, the less likely it'll happen. It's often a concern that'll discourage me from contributing to projects for example as I've got enough on my plate to suss out already 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we had this discussion already, but it does not lead anywhere. I am currently not willing to switch to NuShell. This is not because I think NuShell is inferior (on the contrary, I think it's probably better). But because no one has the time to rewrite this project not can we maintain it efficiently afterward, etc.
Given we went over this with Rust - which I deem to be superior to NuShell for DMS as a whole - we do not need to extend it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But because no one has the time to rewrite this project not can we maintain it efficiently afterward, etc.
If someone wants to port DMS and maintainers were open to it, that's up to the contributor to handle the rewrite. Bigger issue isn't that contributor time it's the review process, one thing to support a port, another to confidently review something unfamiliar 👍
After that point, I don't think it'd have a negative impact on maintenance tbh.
Given we went over this with Rust - which I deem to be superior to NuShell for DMS as a whole - we do not need to extend it here.
One of the issues with Rust was that it was compile time, rather than the flexibility of an interpreter running arbitrary scripts like bash and python. Nushell was identified as alternative that had perks of rust, but more similar to bash for development without the issues raised with python 😅
Don't mind me though, just an occasional rant about gripes with bash. End of the day there's still two maintainers that are quite comfortable with bash and I am very familiar with our past discussions on the topic, I am just concerned about the bus factor there vs reducing maintenance complexity in a way that more contributors could easily understand what they're reading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given we went over this with Rust - which I deem to be superior to NuShell for DMS as a whole - we do not need to extend it here.
One of the issues with Rust was that it was compile time, rather than the flexibility of an interpreter running arbitrary scripts like bash and python. Nushell was identified as alternative that had perks of rust, but more similar to bash for development without the issues raised with python 😅
Agreed, that is indeed an upside! I am sure we can find many upsides, and we could even compare all approaches. But I, too, think that no one will rewrite this any time soon. I am still open, if anyone wants to try :D
Co-authored-by: Casper <[email protected]>
georglauterbach
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍🏼
Needs a rebase, but other than that - nice!
|
Bit caught up atm, but I'll rebase and merge after 15.0.2 release once some other tasks I'm juggling are resolved 😓 |


Description
Up to you if you'd like to include this in DMS
15.0or DMS15.1. As this is only a change for a setup CLI command, it's not something I'd consider breaking, and functionality wise it should be roughly the same. Tests also seem to indicate all is well 👍I recently did some refactoring on this command while going over unifying our DKIM feature support.
main()method similar to other setup CLI commands._create_opendkim_configs().whileloop only needs to append entries, so is easier to grok._create_dkim_key()to scope just the logic (and additional notes) to key generation viaopendkim-genkeywhileloop of the script occurs in_generate_dkim_keys():whileloop as that seems more appropriate than per iteration.Overall this should be nicer to grok/maintain. Some of this logic will be reused for the unified DKIM generation command in future, which is more likely to shift towards all domains using the same keypair by default with rspamd/opendkim config generated at runtime rather than reliant upon DMS config volume to provide that (still expected for private key).
Type of change
Checklist
CHANGELOG.md