summaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md50
1 files changed, 29 insertions, 21 deletions
diff --git a/README.md b/README.md
index df6db66..3e97c8c 100644
--- a/README.md
+++ b/README.md
@@ -1,19 +1,22 @@
# Source Layout
-The source tree maps to the DNS namespace that we own. The purpose of this
-mapping is to keep things organized hierarchically in how they are deployed on
-the Internet. The main 'common' space is `com.simatime`, everything else should
-be related to the application.
+The source tree maps to the DNS namespace that we own. The purpose of
+this mapping is to keep things organized hierarchically in how they are
+deployed on the Internet. The main 'common' space is `Com.Simatime`,
+other namespaces should be related to the application.
-Development aspects should be localized to their sub-namespaces as much as
-possible. Only after sufficient iteration such that interfaces are solidified
-and functionality is well-established should some code be promoted up the
-namespace hierarchy.
+Development aspects should be localized to their sub-namespaces as much
+as possible. Only after sufficient iteration such that interfaces are
+solidified and functionality is well-established should some code be
+promoted up the namespace hierarchy.
Boundaries and interfaces between namespaces should be small and
-well-defined. Likewise, the functionality and purpose of a particular namespace
-should be small and well-defined. Following the unix principle of "do one thing
-and do it well" is advised.
+well-defined. Likewise, the functionality and purpose of a particular
+namespace should be small and well-defined. Following the unix principle
+of "do one thing and do it well" is advised.
+
+For building the code, we use `nix` and basically copy the namespace
+hierarchy into the main build file `./default.nix`.
# Development
@@ -21,31 +24,36 @@ To build code, do:
nix build -f default.nix <thing>
-To get a repl:
+To get in the environment for a thing, use `nix run`. For example, if
+you want `ghci` with packages for `ibb`, do this:
- nix run -f default.nix <thing>
+ nix run -f default.nix Com.InfluencedByBooks.ghc && ghci
And to deploy:
nix copy --to ssh://root@simatime.com ./result
ssh root@simatime.com $(realpath ./result)/bin/switch-to-configuration switch
+These three common tasks are captured in the `./bild`, `./ghci`, and
+`./push` scripts.
+
# Goals of the developer workflow:
- have minimal ceremony
- default to asynchrony, but allow for synchronous work when necessary
- automate the boring stuff
-- standardize environments, tooling, and versions to minimize friction while
- collaborating
+- standardize environments, tooling, and versions to minimize friction
+ while collaborating
- support the longevity and self-sustainability of the project
-Ideally, each contributor should be able to go off grid for a day or a week or
-more, continue working offline, submit their work when finished, and have no or
-minimal conflicts. This also refers to the resilience of the production systems.
+Ideally, each contributor should be able to go off grid for a day or a
+week or more, continue working offline, submit their work when finished,
+and have no or minimal conflicts. This also refers to the resilience of
+the production systems.
-We should never need "out of office" email auto-replies, or urgent contact. No
-pager duty, no daily stand-ups. Yes, this policy will affect what code we write,
-not just how we write it; that is by design.
+We should never need "out of office" email auto-replies, or urgent
+contact. No pager duty, no daily stand-ups. Yes, this policy will affect
+what code we write, not just how we write it; that is by design.
## Org