Second Draft
We need to adapt to Nix now being a language with a proper module system, considering flakes to be essentially equivalent to a module in other languages. This should help create clear and distinct lines between different elements of the system, and keeps private code from leaking. For example, profiles could be it's own subflake of DevOS, which exports all profiles as nixosModules to then be consumed by the parent flake. Not every directory need be a flake, and many of the existing directory folders could be grouped together in a shared flake to reduce the complexity of the filesystem layout, without sacrificing any of the already established conveniences of DevOS.
This has the added benefit of allowing power users to pull only relevant pieces of DevOS, such as it's lib, in a flake ref: "github:divnix/devos?dir=lib".
Impetus
In a word: complexity.
From the very first moment of deploying DevOS to the world, I knew the fs hierarchy had to change. I was hoping to illicit feedback from the community. As an example, one of the complaints I hear echoed is the default imports, which happen it different ways in different places, and if kept at all should definitely be reduced to a simpler implementation. This issue will remain open until a solid layout has been decided on, so we don't have to continue changing it out from under users. I want a flake centric approach, and internal flakes seem like the right way to manage access, at least from a high level.
For example, with this approach we should be able to maintain the convenience of the current doc setup, i.e a README.md in every directory explaining it's use, without actually needing the book.toml and SUMMARY.md in the root. We can just pull in the src flake to the doc flake, and overlay the book.toml onto it to generate the book.
Once a demo is achieved that maintains all the established conveniences of current DevOS, and a proof-of-concept for #127, I will open a PR that we can then scrutinize.
Changes
We would turn off the github template, and generate the template as a derivation with the docs optionally included for users. This will eliminate one level of nesting for users, while also eliminated irelevant code from the users template.
Goal
This won't change once 1.0 is reached, so we need to get it right, aiming at convenience for users without restricting what they can do.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Second Draft
We need to adapt to Nix now being a language with a proper module system, considering flakes to be essentially equivalent to a module in other languages. This should help create clear and distinct lines between different elements of the system, and keeps private code from leaking. For example, profiles could be it's own subflake of DevOS, which exports all profiles as
nixosModulesto then be consumed by the parent flake. Not every directory need be a flake, and many of the existing directory folders could be grouped together in a shared flake to reduce the complexity of the filesystem layout, without sacrificing any of the already established conveniences of DevOS.This has the added benefit of allowing power users to pull only relevant pieces of DevOS, such as it's lib, in a flake ref:
"github:divnix/devos?dir=lib".Impetus
In a word: complexity.
From the very first moment of deploying DevOS to the world, I knew the fs hierarchy had to change. I was hoping to illicit feedback from the community. As an example, one of the complaints I hear echoed is the default imports, which happen it different ways in different places, and if kept at all should definitely be reduced to a simpler implementation. This issue will remain open until a solid layout has been decided on, so we don't have to continue changing it out from under users. I want a flake centric approach, and internal flakes seem like the right way to manage access, at least from a high level.
For example, with this approach we should be able to maintain the convenience of the current doc setup, i.e a README.md in every directory explaining it's use, without actually needing the book.toml and SUMMARY.md in the root. We can just pull in the
srcflake to thedocflake, and overlay the book.toml onto it to generate the book.Once a demo is achieved that maintains all the established conveniences of current DevOS, and a proof-of-concept for #127, I will open a PR that we can then scrutinize.
Changes
We would turn off the github template, and generate the template as a derivation with the docs optionally included for users. This will eliminate one level of nesting for users, while also eliminated irelevant code from the users template.
Goal
This won't change once 1.0 is reached, so we need to get it right, aiming at convenience for users without restricting what they can do.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.