Matsubaa/FedDIY
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Update documentation to clarify Nix usage and enhance onboarding for non-Nix contributors

Browse Source
This commit is contained in:
Kyle J. Turpin
2026-05-23 18:17:47 -05:00
parent 94c7cadcd7
commit 2ecab4db12
4 changed files with 21 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ARCHITECTURE.md
+2 -2
View File
@@ -21,12 +21,12 @@ Out of scope for early phases:
FeDIY is intended to be shipped and operated through a small set of first-class packaging targets so instance operators can choose the deployment style that fits their environment:
- **Nix flake/devShell**: reproducible development and build environment for contributors and operators who prefer Nix.
- **Nix flake/devShell**: reproducible development and build environment for contributors and operators who prefer Nix. It is a convenience path, not a requirement for contributing.
- **Flatpak**: desktop-friendly distribution path for bundled client or companion tooling where applicable.
- **OCI/Docker container image**: a standard containerized deployment path for managed hosting, Kubernetes, and simple `docker compose` installs.
- **NixOS module**: optional system integration for operators already using NixOS.
These targets should share the same application artifact and configuration model where possible. Packaging differences should be limited to how the binary is delivered, configured, and run; they should not fork the core runtime behavior.
These targets should share the same application artifact and configuration model where possible. Packaging differences should be limited to how the binary is delivered, configured, and run; they should not fork the core runtime behavior. Contributors should be able to work productively with standard Rust tooling even if they never enter the Nix shell.
The flake and related packaging shells should be reviewed periodically so the included tools stay aligned with current phase needs. The default posture is to keep the dev environment lean and add tools only when they directly support active work such as building, testing, localization, accessibility validation, container packaging, or release tasks.