| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Passed strings will be treated as a relative path below the given root,
which is quite convenient when using depot.path by eliminating a lot of
repetition.
Change-Id: I3da6058094484f4a6ffbb84f89ad4472b502a00c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3704
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Since //web/bubblegum depends on nint, we need to move it to a non user
directory to conform with the policy established via cl/3434.
Note that this likely doesn't mean greater stability (which isn't
really implied in depot anyways), since I still would like to use a more
elaborate calling convention to allow for additional useful features.
Change-Id: I616f905d8df13e3363674aab69a797b0d39fdd79
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3506
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Using sparseTree we can make a (surprisingly long) list of things from
depot the examples depend on and create a stripped down depot version
which only contains them. As a result the examples are no longer rebuilt
on every commit.
Change-Id: I3693570ca4bdbbf9da795e552f278f3b1b1b77a9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3504
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
This is a wrapper around baseNameOf which also can deal with
derivations. Added to //nix/utils since I've found myself introducing an
ad-hoc implementation of this for both //web/bubblegum and //nix/buildC.
Change-Id: I2fcd97a150d6eda21ab323fa0d881ff7442a892e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3049
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Instead of having two ways of accessing the path to the depot (one of
which was stuttering, depot.depotPath) we settle on only one:
depot.path.
This was mostly used for NixOS module imports.
Co-Authored-By: Florian Klink <flokli@flokli.de>
Change-Id: I2c0db23383fc34f6ca76baaad4cc4af2d9dfae15
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2962
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
The whole pass the name of the status as a string thing was mostly born
out of an overeager use of yants. It is still very neat especially for
common cases like "OK", so we'll keep it, but also allow passing the
integer variant of the status as well which probably feels more natural
for a lot of people, especially over getting the casing right for
"I'm a teapot".
Change-Id: I3f012a291447ef385efdd28132292a8b331998c0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2850
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
We can actually catch some errors that may be generated in bubblegum
applications where we can report them to the user in a way that doesn't
require curl -vv:
* Type errors in the status argument: By removing yants completely we
not only (presumably) gain some performance, but also the ability to
return an internal server error on an unexpected type instead of
throwing.
* User generated evaluation errors: by using builtins.tryEval we can
catch throws and asserts the user inserted when generating the body
and report to the user that something went wrong. To do: also support
for the headers.
Change-Id: I8363b9825c6c730e624eb8016a5482d63cbc1890
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2849
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
So here is what has been keeping me up at night: At some point I
realized that nix actually made a somewhat passable language for CGI
programming:
* That `builtins.getEnv` exists as one of the impurities of Nix is
perfect as environment variables are the main way of communication
from the web server to the CGI application.
* We can actually read from the filesystem via builtins.readDir and
builtins.readFile with bearable overhead if we avoid importing the
used paths into the nix store.
* Templating and routing are convenient to implement via indented strings
and attribute sets respectively.
Of course there are obvious limitation:
* The overhead of derivations is probably much to great for them to be
useful via IfD.
* Even without derivations, nix evaluation is very slow to the point
were a trivial application takes between 100ms and 400ms to produce a
response.
* We can't really cause effects other than producing a response which
makes it not viable for a lot of applications. There are some ways
around this:
* With a custom interpreter we could have streaming and multiplexed
I/O (using lazy lists emulated via attrsets) to cause such effects,
but it would probably perform terribly.
* We can use builtins.fetchurl to call other HTTP-based microservices,
but only in very limited constraints, i. e. only GET, no headers,
and only if the tarball ttl is set to 0 in the global nix.conf.
* Terrible error handling capabilities because builtins.tryEval actually
doesn't catch a lot of errors.
To prove that it actually works, there are some demo applications,
which I invite you to run and potentially break horribly:
nix-build -A web.bubblegum.examples && ./result
# navigate to http://localhost:9000
The setup uses thttpd and executes the nix CGI scripts using
users.sterni.nint which automatically passed `depot`, so they can
import the cgi library.
Change-Id: I3a22a749612211627e5f8301c31ec2e7a872812c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2746
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
