Replies: 1 comment
-
|
See the comment at #21 (reply in thread) tl;dr. they are both aspect-trees implemented with the The flake-aspects project (at the time of its inception) was just about transposition, its core is a simple transpose lib that just swapped attributes at second level, turning flake.aspects.. into flake.modules... That was the original feature. Then as den came to life, I started realizing I needed some support for tree-like structure of aspects (provides) and dependency graph (includes), both were integrated into the flake-aspects project since module resolution (aggregating all dependent modules) is part of the transposition. den initially generated new aspects in flake.aspects attribute, but I found that in doing so, any aspect that is added to flake.aspects is automatically transposed (and exposed) as part of flake.modules. For den, this means that if you have lots of hosts, and users, each of them will polute the flake.modules namespace. Your flake will expose lots of things particular to your (maybe-private) host/user names. So I decided for den to have its own private aspects namespace (it is actually just created with the flake-aspects project), and thus you have den.aspects and den.modules the only difference is they are not automatically exposed as part of the flake output, but you still have the option of exposing any part of them into flake.aspects.foo = den.aspects.foo or even just resolved modules: flake.modules.nixos.foo = den.modules.nixos.foo, you have freedom to choose what is exposed outside your flake. That's the reason behind den.aspects, it is just an aspect namespace implemented itself solely by the flake-aspects library. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Since
denuses theflake-aspectslibrary, why not useflake.aspects? What is the purpose ofden.aspects?Beta Was this translation helpful? Give feedback.
All reactions