| Age | Commit message (Collapse) | Author |
|---|
|
I was getting confused about what is a product and what is internal
infrastructure; I think it is good to keep those things separate. So I moved a
bunch of stuff to an Omni namespace, actually most stuff went there. Only things
that are explicitly external products are still in the Biz namespace.
|
|
This patch does a few things:
1. Switches from nixpkgs-unstable to nixos-unstable{,-small}, simply because
nixpkgs-unstable is not in cache.nixos.org, but nixos-unstable is, and -small
is the same but requires all tests to pass. So we should prefer
nixos-unstable-small, whenever possible.
2. Reorganizes the nixpkgs import code such that Nixpkgs.nix returns an attrset
of all the nixpkgs that I want to use, rather than putting other nixpkgs
branches into the main one as an overlay. This is much simpler and explicit,
but it meant I had to change a lot of usages throughtout the nix codebase.
3. As a consequence of 2, moves the overlays into separate files so they can be
re-used across nixpkgs branches.
|
|
nixfmt is the soon-to-be official formatter for Nix code, as per the NixOS
GitHub group. So I figure I should just adopt it without worrying too much about
the specifics of the formatting. I just formatted everything in one go, hence
the huge diff, oh well.
|
|
Mostly thid required packaging up some deps, but also had to recompile
stuff with cuda support.
|
|
Also had to capitalize some stuff, and move some nix files around and rename
the metadata directive from 'exe' to 'out' because that just makes more sense,
and fix some compiler errors. But now bild treats both nix and hs files as
buildable things. So that's cool.
One interesting example is Biz/Pie.{nix,hs} - I can either create a dev build of
the hs file with ghc, or I can create a fully-encapsulated nix build. Its nice
to have both options because a dev build with ghc takes half the amount of time,
and I can rely on my locally cached hi and ho files. I think this shows the
power of bild, but also can be a somewhat subtle thing.
The issue really is with the separate command calls in nix builds vs dev builds.
I figure there are a few ways to fix this:
1. Try to use bild inside the nix rules. That could be interesting, but could
also lead to some weird behavior or worm holes forming.
2. Extract the command line invocation into a separate file, some kind of
really simple template that gets pulled into both programs.
It is important to consider that in the future I might want to have bild do a
module-by-module nix build of programs, but I'm not sure how that would effect
my choice here.
|
|
Also correctly renamed the files (didn't work the first time thanks to
the macOS filesystem) and moved the default build.os settings to a
OsBase.nix file to be used via imports.
|
|
|
|
|
|
|
|
Working toward https://github.com/bsima/biz/issues/5
|
|
|
|
I also restructured some types so that I could grab a handle on the keep to
close it on shutdown, otherwise the database would be locked and I can't do
anything about it. This might mean I have to delete and start the database from
scratch when I deploy, but that's okay because I haven't stored anything yet.
I also renamed some stuff like 'deck' and 'beam' just for fun. I could make
these into more general interfaces like I always planned to.
Also I haven't really tested this yet, so... next commit will implement the user
login.
|
|
|
|
This is somewhat experimental, the idea is automatically set the sources
from my niv pinned deps. It seems to work, so I'll keep at it and see if
I can improve it as issues come up.
|
|
|
|
Bash prompts don't show anything beyond the first '.', so this makes
them readable
|
|
Moving away from the DNS-driven namespacing toward more condensed names,
mostly because I don't like typing so much.
|
|
|
|
This also includes some drive-by formatting changes and config changes
needed to get it up and running.
|
|
I still have to reimplement the SSL stuff but in the Haskell code. That
seems kinda hard or at least requires research that I don't wanna do
right now.
|
|
I stored them in my org files.
|
|
I also had to refactor the overlays stuff a bit, but it is much nicer now.
|
|
This also allowes me to make 'repl' into a universal command. This makes
it much easier to work across different projects.
|
|
|
|
|
|
|
|
I wanted to even further simplify the build tooling overhead. My general
goal is to not have to think about declaring packages, or dependencies,
or really anything that you might find in a cabal file. Not all of these
goals are possible, but we can get pretty close. With this commit all I
need for the 'buildGhc/buildGhcjs' functions is the path to the
entrypoint file; everything else is either inferred by the Nix code or
declared in the Haskell code comments.
The strategy is to map a Haskell module to an executable artifact, and
pass just that module to 'ghc --make'. Then we can rely on ghc to handle
walking the local filesystem for imports. The only thing ghc really
needs to know is a name for the output executable; it is hard to
automatically infer this, so we have a simple comment syntax to declare
this in the file. The comment syntax is inspired by existing Haskell
'LANGUAGE' pragmas; having this in the same file keeps the configuration
as close to the real code as possible. The Nix code then extracts this
info from the code comments, and sets the required ghc flags.
Second, we need to declare the set of 3rd-party packages that our
program relies on. For this we can re-use the same comment syntax and
just list the dependencies, then extract them in Nix and construct a
package set as we were before.
This reduces the amount of "package declaration" code we have to write
in default.nix, and reduces the amount of time we have to spend
switching between the Haskell code and the Nix code (I find such context
switching super annoying). I also think having the configuration in with
the Haskell code encourages us to write smaller, simpler modules and
only write code that we need.
Additionally, I refactored the bild and ghci (now called 'repl') scripts
to work in any directory. The .envrc uses direnv to set the path so that
you can run these scripts anywhere. That means the following works:
$ cd Run/Que
$ bild Website
$ repl Server
λ> :l Run.Que.Server
I find this to be a rather nice workflow.
|
|
|
|
|
|
curl was throwing an exception if the file got too long, because I was
passing the entire file contents in the arguments to curl. I tried using
a tmp file but that didn't work for some reason. So I switched to req
and that seems to work well.
I also made it faster by serving all pages concurrently, and I spruced
up the CSS a ton.
|
|
This is a simple website server that uses que.run itself to host the que
webpages.
I had to rename Run.Que to Run.Que.Server because nix was
complaining about Run.Que being both a derivation and an attrset with
Run.Que.Website in it.
|
|
I'm using serval.simatime.com as a catch-all production app server for
now. The 'que.run' domain is pointed at that instance, and the service
is just installed as a regular NixOS systemd service.
I had to do some troubleshooting because I wasn't getting any DNS names
to resolve. I think changing the nameservers fixed it. Don't know why
the 127 number was in there.
Another issue concerns how to add our packages to the set of nixpkgs in
the generated NixOS. I played around with this for a while and landed on
using an overlay to put our set of packages under 'pkgs.biz.<name>', and
then passing that in to the 'buildOS' function. This isn't really the
best solution because it is confusing and rather disconnected. I'm
starting to realize that it might be good to separate nix artifacts into
"machines" and "programs", but I don't want to do that just yet. I'd
like to finish designing my bild program before making any large design
decisions or re-organizations.
|
|
Now that I have the domain name que.run! Aw yeah.
|
|
|
|
Two functions makes it simpler to reason about what is being built and
when, even if it is a bit more explicit. I also removed the dumb
Apex/Aero naming thing because Server/Client is just easier to remember.
|
|
Hopefully this won't break anything...
|
|
This is convenient for building stuff in our nixpkgs pin.
|
|
|
|
|
|
|
|
I don't have runserval.com yet, so I'm not gonna put the cart before the horse
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
