Noting here for future inspections: test fails randomly (and this test is not associated with the changes in any way)

not ok 32 checking dovecot mailbox format: mdbox file created in 31119ms
# (from function `repeat_until_success_or_timeout' in file test/test_helper/common.bash, line 51,
#  in test file test/tests/serial/mail_with_mdbox.bats, line 28)
#   `repeat_until_success_or_timeout 30 docker exec mail_with_mdbox_format /bin/sh -c '[ $(ls /var/mail/localhost.localdomain/user1/storage/m.1 | wc -l) -eq 1 ]'' failed

There is parsing of ls involved .. This needs to change :D

Noting here for future inspections: test fails randomly (and this test is not associated with the changes in any way)

They're due to the Postfix wrapper removal I think, that's where I first saw them pop up, but forgot to PR revised versions of those tests in response 😅

Presumably (I haven't looked at the tests yet) they fail now because Postfix loads faster which likewise broke the amavis spam tests (that did get fixed).

Noting here for future inspections: test fails randomly (and this test is not associated with the changes in any way)

They're due to the Postfix wrapper removal I think, that's where I first saw them pop up, but forgot to PR revised versions of those tests in response 😅

Presumably (I haven't looked at the tests yet) they fail now because Postfix loads faster which likewise broke the amavis spam tests (that did get fixed).

IIRC I have seen them even before your change to Postfix, so I think they might actually be unrleated. They are a timing issie though, I agree, since our CI is running faster and faster.

I would like to see the method use the same test coverage that configomat has, I detailed those in an old issue where I proposed a rust port.

Agreed; I can add such tests.

If you're open to introducing rust into the project, it might also be an alternative option. The rust version is a bit more thorough and verbose, but I'd argue easier to maintain for most than all the shell voodoo going on for this utility method 😅 (unless you're @casperklein and @georglauterbach of course who have crazy good shell-fu skills)

To start things off: I love Rust. I think it is by far the best programming language out there. Im using Rust in private and at work, almost every single day. So from a maintenance point of view, I can definitely handle it.

But I guess this is not enough, not even close. Before we get going with Rust, and I am not against that really, we need to make up our mind what this would look like. In the meantime, I'd go forward with Bash.

We would need to answer a few important questions:

1. Can people maintain the Rust code? (I actually think that the Bash code we deploy right now is pretty high-class, but sometimes also hard to understand as a consequence. Therefore, maintaining Rust would probably solely depend on the amount of people that can actually program in Rust?)
2. What would the integration look like? Would there be Rust code in this project? Would you package it, or build it when building the container?

I would like similar rust code to handle other areas of the project, especially with the user management, but need other maintainers to be comfortable with rust in the project as I am likely to have reduced availability in the future for DMS.

I think DMS could profit from Rust as well. But we should have a dedicated maintainers discussion or an issue for this topic IMO.

Noting another spurious test failure here:

not ok 42 checking dovecot mailbox format: sdbox file created in 30905ms
# (from function `repeat_until_success_or_timeout' in file test/test_helper/common.bash, line 51,
#  in test file test/tests/serial/mail_with_sdbox.bats, line 28)
#   `repeat_until_success_or_timeout 30 docker exec mail_with_sdbox_format /bin/sh -c '[ $(ls /var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1 | wc -l) -eq 1 ]'' failed
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# ls: cannot access '/var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1': No such file or directory
# Timed out on command: docker exec mail_with_sdbox_format /bin/sh -c [ $(ls /var/mail/localhost.localdomain/user1/mailboxes/INBOX/dbox-Mails/u.1 | wc -l) -eq 1 ]

Before we get going with Rust, we need to make up our mind what this would look like. In the meantime, I'd go forward with Bash.
We would need to answer a few important questions:

For quite some time now, the active maintainers have effectively been 3 of us. I've learned more about bash / shell scripts through you two, but if I'm not actively using those skills I forget what the syntax / features are and will need to look up again how to interpret what I'm seeing.

As you're already comfortable with Rust, this mostly flips the DX issue from me to casper. But as I am likely to become less active as a maintainer here, that could be a concern.

On the plus side, I can't say that bash has attracted many contributions, and definitely not more maintainers. There's been multiple times where I've had to lose time into figuring out how to do something with bash / commands that would be much simpler with a language like rust (or even python 😬 ), especially if that's nested arrays and parsing / editing files.

As long as there's already a solid foundation of rust introduced, that upfront knowledge is taken care of and isn't likely to cause much maintenance burden. I think there would be less need to reach out to a search engine / docs as the syntax of what is going on is often more obvious. Plus if something goes wrong the compiler is pretty good at telling you where and often how to fix it.

Rust experience from contributors probably won't be any more common than decent bash, so it may not help attract more maintainers. I do think it is easier to maintain with proper modules vs the "globals" sourcing approach we tend to take with shell scripts. There is also less portability issues (macOS / Windows contributors, and even linux like my local grep misbehaving vs rg).

What would the integration look like? Would there be Rust code in this project? Would you package it, or build it when building the container?

That's a good question. For CLI like programs, those could be separate repos, but once you start porting the bulk of shell scripts, then it would need to be part of this project.

• When it's CLI programs, you could just have a CI build and publish artifacts that can be pulled into a main Dockerfile.
• Once replacing core scripts, then it's being updated more frequently and tied more heavily to what goes on in this repo, thus needs PRs for traceability to not fall out of sync like we used to have with features and the old Github wiki. We'd probably be building in the container at that point?

I think DMS could profit from Rust as well. But we should have a dedicated maintainers discussion or an issue for this topic IMO.

Yeah all good. My focus right now is to get the project where I'd like it to be first, so that's with bash.

If I then find time to propose introducing some rust I'll raise a proper maintainer discussion about it 👍

Noting another spurious test failure here:

I'll tackle those tests today if you've not already started 😅

Documentation preview for this PR is ready! 🎉

Built with commit: 71fd6fa