mirror of
https://github.com/nix-community/home-manager
synced 2024-11-09 12:49:44 +01:00
7 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
David Baynard
|
41790ba656
|
mbsync: extend config type with list of strings
Some configuration options can take space separated strings; for
example `SSLVersions` can be configured with multiple allowed
versions.
SSLVersions TLSv1.3 TLSv1.2
This can now be represented in Home Manager.
SSLVersions = [ “TLSv1.3” “TLSv1.2” ];
In implementing this change, it uses oneOf for config type, as it is a
cleaner way to represent the union than the nested eithers
formulation.
Also add SSLVersions to test lists of strings in
`account.extraConfig`.
|
||
Robert Helgesson
|
134c5ccdd3
|
mbsync: stub test dependency | ||
Karl H
|
64607f58b7
|
isync/mbsync: replace master/slave with far/near (#1776)
* isync/mbsync: replace master/slave with far/near isync/mbsync: update tests to match new changes * isync/mbsync: use mkRenamedOptionModule to alert user to near/far change * isync/mbsync: use warnings to alert about master/slave far/near change Fix capitalization isync/mbsync: fix nitpicks * isync/mbsync: run format script * isync/mbsync: include new test for expected master/slave warnings * isync/mbsync: add news about changes |
||
|
Karl H
|
96d7de6db1
|
mbsync: per account multiple channels (#1360)
* mbsync: option for configuring a channel
A channel is a relationship between 2 directories/boxes/mailboxes
between the local machine (slave) and the remote mail server (master).
Each channel must be given at least:
* an account-unique name
* a pattern for which mailboxes to sync from master
* a pattern for what directory where that mail ends up on the
slave
Additional options can be added later.
* mbsync: option for configuring a group
A group is a grouping of channels together, so that many channels with
very different names can be handled as a single entity.
Groups are unique in mbsync because they will shadow channels that
have the same name on the command-line.
* mbsync: create groups configuration attribute
This is the end of the configuration that the end-user will use.
They will specify an attribute set that contains the name for the
group, so they can say
`accounts.email.accounts.<aname>.groups.<gname>` to access the
configuration for the group with the name `<gname>`.
* mbsync: write function to generate group-channel blocks
This function takes in a set of groups, and their consituent
channels and writes the appropriate .mbsyncrc block. The block is as
shown below:
Group groupName1
Channel channelName1
Channel channelName2
Group groupName2
Channel channelName3
Each group must have a unique name, no matter which account it is
declared under. The same holds true for channels. However, if there is
a group that shares the same name as the channel, the channel will
effectively be "shadowed" by the group, and mbsync will default to
working with the group in that case.
* mbsync: write function to generate channel configuration blocks
This function takes in a set of groups, which includes their
consituent channels and writes the appropriate .mbsyncrc block for the
channel. The block that is generated is shown below:
Channel groupName1-channelName1
Master :<accountName>-remote:<master-pattern>
Slave :<accountName>-local:<slave-pattern>
Channel groupName2-channelName2
Master :<accountName>-remote:<master-pattern>
Slave :<accountName>-local:<slave-pattern>
Each group must have a unique name, no matter which account it is
declared under. The same holds true for channels.
Using channels with the patterns set up this way allows one to specify
which maildir directories are to be synchronized FROM the master TO
the slave. In addition, it allows for these maildirs to be remapped,
between the master server and the local slave.
This is critical, because Gmail has a strange way of storing its mail
that makes using mbsync, mu, and mu4e more difficult.
There are additional channel parameters that are already present in
this codebase from the previous use of group-channel configuration,
which will be reused.
* mbsync: set the submodule's names field according to parameter
This is the same method as is used in creating an email account, named
`<name>` under `accounts.email.accounts.<name>`. This allows the user
to specify groups and channels, in a list-like format, but still gets
the "namespacing" to more easily handle the options available in each
of these locations.
* mbsync: provide examples of master/slave patterns for channels
* mbsync: create nested-let function to generate channel pattern
This pattern is required to either NOT be present, which means the
master pattern is used to match, or it has a list of patterns to use
beneath the master maildir to match against.
This function checks to ensure that if patterns is not empty, ONLY
then is the `Pattern` keyword printed. Otherwise, there are many, many
problems.
If there IS a list of patterns, then we use proper escaping methods to
ensure that the exact string is constructed.
* mbsync: per-account groups can have additional patterns
Gave the
`accounts.email.accounts.<name>.mbsync.groups.<gname>.channel.<cname>`
set a `patterns` option, which will allow for greater customization
and filtering of the master maildir to sync to the slave maildir.
* mbsync: add extraConfig option for easier-to-format options
These are options that can be handled by the `genSection` function in
the `genAccountFunction`, so they are left to the user to decide.
Most of these are made on a global basis anyways.
* mbsync: remove unneeded extraConfig.channel
This was originally placed here, seemingly, just to get this module
working. However, this field is actually more confusing now that a
separate per-channel configuration option for extra configurations has
been made available.
* mbsync: correct and improve comment in masterPattern description
* mbsync: switch channel/group generation to new functions
Changing this out is what moves us from the old system to the new one.
Instead of having a single channel manage a whole mailbox, we can now
specify an attribute set of groups that should correspond to an email
account.
Each of these groups contains an attribute set of channels that make
it up, and are grouped together for synchronization. In addition, each
of these channels can have additional IMAP4 parameters attached to
them to further refine synchronization.
Lastly, each of the channels is grouped together under the Group
section, ensuring that the channels' mailboxes synchronize as they
have been specified.
* mbsync: only generate group/channel configuration if channels present
Typically, when a group is specified, channels will be specified as
well. However, if due to error or mistake, the user forgets to specify
ANY channels for a group, we should not generate that group's
information.
This means that no channels are specified (which maps the remote
master to local slave). In addition, the `Group <gName>` block (which
brings the separate channels together) is also not generated.
Another thing to consider is that a user might specify a group and a
channel, but perform no additional configuration of the channel.
In a configuration, this would be realized by
`accounts.email.accounts.<aName>.mbsync.groups.<gName>.channels.<cName>;`
This creates the channel with the name `<cName>` and the
`masterPattern`, `slavePattern`, and `patterns` fields use their defaults.
By definitions set within mbsync, these defaults actually specify that
the remote master's `INBOX` mail directory is synchronized to the
local slave's `INBOX` directory.
So, if there is a channel that has no fields specified, then we DO
want to generate its configuration. But if there is a group that has
no channels, then we do NOT generate it.
* mbsync: acc comment explaining why groups attr set is never empty
* Revert "mbsync: remove unneeded extraConfig.channel"
This reverts commit
|
||
|
Robert Helgesson
|
95b95b1407
|
tests: improve test purity
Before the XDG variables would be set from the user's environment, if available. This would break some tests. With this change the tests should be fully deterministic. Fixes #1190 |
||
|
Robert Helgesson
|
45abf3d38a
|
Apply nixfmt on many files
|
||
|
Robert Helgesson
|
de8033747c
|
tests: clean up tests
- Move all module tests to their own directories. - Avoid duplication of `// import`. |
Renamed from tests/modules/programs/mbsync.nix (Browse further)