Change:
</varlistentry> <varlistentry> <term> <ins> <literal>types.raw</literal> </term> <listitem> <para> A type which doesn’t do any checking, merging or nested evaluation. It accepts a single arbitrary value that is not recursed into, making it useful for values coming from outside the module system, such as package sets or arbitrary data. Options of this type are still evaluated according to priorities and conditionals, so <literal>mkForce</literal>, <literal>mkIf</literal> and co. still work on the option value itself, but not for any value nested within it. This type should only be used when checking, merging and nested evaluation are not desirable. </para> </listitem> </varlistentry> <varlistentry> <term> </ins> <literal>types.attrs</literal> </term> <listitem>

Discussion:
If I have an option of type and I assign an attrset with , the configuration of will see its name as . This is because is which follows the default merging rules, but I'm not sure how to fix it (or if it's working as designed). system: host os: multi-user?: sandbox: version: channels(sean): channels(root): nixpkgs:
This was my attempt but it seems to break things horribly.
I'm not saying, that issue will be fixed when you provide reproduction steps of your issue, but that would be a great start. For example, I don't follow where option comes from
Sure, let me see if I can provide a MWE so people can play with it. The root cause is in the issue description, though, afaict. This configuration:
yeah, nasty bug. I've combined your example into one file: And result of invocation: I can't think of what exactly is wrong here. Surely, shouldn't merge. But should this code pattern be allowed at all? cc
The problem might be located here: But then the question becomes, should the be inherited? What about: Surely is expected to be the name.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still a problem, here's a repro that works after
I marked this as stale due to inactivity.

&rarr;
replacing by () seems excessive, losing the ability to . What about ? It seems to have a reasonable merge function.
See , and co. still work. would be too strict for things like , where it would recurse into the whole thing
This change is unfortunate. Right now we place utility functions into , and this happens across several modules (split across several git repositories, even). This change breaks this ability and likely affects more users that haven't started migrating yet. Could we perhaps change to a submodule with freeformType undefined, such that individual options like can pick their suitable merge strategy?
This is asking for trouble. Logic is better represented by either that compute (e.g. ), or expressions that you can import as usual The latter is easiest to test. We'll want to set its freeformType to though, as has always been open for extension like that. The point of freeformType is that it doesn't prevent the improvement of types. Since , you don't even have to specify that you're type-merging with the submodule anymore, so you'd be able to say directly: .
I don't think we have a viable solution within the module system. For now I can only recommend to avoid merging in . You can merge in another option beforehand if you must. E.g. .
The reason we have been using is because has been preventing us from using readOnly functions straight in explicit options. Okay, wouldn't that work then? As long as exists, we can inject new options (and pick something other than with mergeable types).