The most trivial of all derivations. It is more useful than it looks.
Can be used to bind nix expressions (e.g. test suites) to a
derivation, so that `nix-build` does not crap itself.
Change-Id: I61c24d8c129c9505733161207f3c30e820f5b15e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/665
Reviewed-by: tazjin <mail@tazj.in>
This is a simple-stupid “unix import system” for nix, for referencing
binaries in `/bin/` by their name and lifting them to a Nix attrset.
Allows for simple aliasing of executable names.
Change-Id: Ifa23cb377201c3b08050c5026e9751e736afaf56
Reviewed-on: https://cl.tvl.fyi/c/depot/+/664
Reviewed-by: tazjin <mail@tazj.in>
This is a very simple test suite for nix expressions.
It should help us set up a good suite of unit tests for our nix-based
stuff.
Since we allow import from derivation, these tests can also depend on
derivations and e.g. use `builtins.readFile` to check outputs.
This is a first PoC to get us going, we can always replace it by
something different in the future if we don’t like it.
Change-Id: I206c7b624db2b1dabd9c73ffce4f87e658919958
Reviewed-on: https://cl.tvl.fyi/c/depot/+/662
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: tazjin <mail@tazj.in>
Has one less value than bool.
Change-Id: I2f2db07b1eb1f49172942bc1d8c6ceb30d987d84
Reviewed-on: https://cl.tvl.fyi/c/depot/+/661
Reviewed-by: tazjin <mail@tazj.in>
This is a writer, similar to `pkgs.writeBashScript` or
`pkgs.writers.writePython3`.
The difference is that we can correctly write all execline scripts by
using nix lists of lists, so the user doesn’t have to care about
escaping arguments (like they have to in bash scripts with
`lib.escapeShellArg` for example).
Change-Id: I2f2874cf61170ddca07b89b692f762725f4a75dc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/625
Reviewed-by: Kane York <rikingcoding@gmail.com>
Reviewed-by: tazjin <mail@tazj.in>
Create a store path where the executable `exe` is linked to
$out/bin/${name}. This is useful for e.g. including it as a “package”
in `buildInputs` of a shell.nix.
For example, if I have the exeutable /nix/store/…-hello, I can make it
into /nix/store/…-binify-hello/bin/hello with
`binify { exe = …; name = "hello" }`.
Change-Id: I600bdcd8f143bca2dd8dfbb165a9a5a8d6397622
Reviewed-on: https://cl.tvl.fyi/c/depot/+/624
Reviewed-by: tazjin <mail@tazj.in>
These functions work like buildGo.program & buildGo.package, but run
the .go2 sources through go2go first before passing them to the
//nix/buildGo equivalents.
Change-Id: Id1ebab6085c390d6986387370181377b9f5d39e8
This skips any directory entries starting with a dot.
Change-Id: I95767f3d35bcb2ed9b3d6e772f3924dd57612711
Reviewed-on: https://cl.tvl.fyi/c/depot/+/123
Reviewed-by: tazjin <mail@tazj.in>
Prior to this patch, github.com/hashicorp/terraform-svchost is
erroneously considered a sub-package of github.com/hashicorp/terraform,
breaking dependency searching:
error: missing local dependency 'github.com.hashicorp.terraform-svchost' in 'github.com/hashicorp/terraform'
Change-Id: Ibcf0f3a9b1742ce46f84cbbf84e90127b8c1df0d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/122
Reviewed-by: tazjin <mail@tazj.in>
This subtree split makes it possible for people to clone only
yants (similar to the kontemplate and journaldriver branches).
The subtree continues the history of the old git repository.
Setting the GOROOT_FINAL environment variables replaces the absolute
location of the Go standard library sources in the final build
artefacts with a fake location (in this case starting with
go/src/...).
This is despite the documentation for 'trimpath' (in 'go tool
compile') stating that it would affect all source paths: That's only
true for user code!
I figured this out by reading through the implementation of the other
'trimpath' (in 'gob build'):
https://go-review.googlesource.com/c/go/+/173345
Adds the necessary attributes on derivations created by
buildLisp.program for them to be passed to buildLisp.sbclWith.
This makes it possible to easily spin up Lisp environments that
contain everything needed for a given program.
I can not currently find a way to set the CFFI variables correctly to
get it to load libraries from Nix.
In the absence of that feature, a wrapper also does the trick.
It's not enough to compile in the right order - turns out you also
have to load the compiled objects in the right order.
To achieve this some cursed code has been added that changes the Lisp
generated by Nix to compile the other Lisp so that it also generates
some bash, which Nix can then use to concatenate the FASLs in the
right order to feed them to Lisp again.
It works but I'll replace it with a more elegant solution once one is
needed.
Similar to buildGo.nix, the library derivations carry information
about their dependencies which is merged when a load file is
instantiated.
The load files are created when compiling libraries, but will in the
future also be created when wrapping SBCL and dumping images.
Adds a Nix function to build a Lisp library out of a specified set of
Nix files. All files are combined into a single FASL.
This is by design only compatible with SBCL (for now).
This moves the various projects from "type-based" folders (such as
"services" or "tools") into more appropriate semantic folders (such as
"nix", "ops" or "web").
Deprecated projects (nixcon-demo & gotest) which only existed for
testing/demonstration purposes have been removed.
(Note: *all* builds are broken with this commit)
Pipes inside of code blocks inside of tables seem to pose a challenge
for some Markdown renderers. Not a problem for Github's but this page
is occasionally embedded in other documentation (such as nixery.dev)
The highlighter expects that all code blocks are valid expressions (to
some degree) and highlights mismatches in dark red, which is not
particularly pleasant for the reader.
This introduces a "fake" attribute set in the `inherit` section to
please the highlighter.
These are not strictly speaking language features, but my intention
for this document is that someone can - after reading it - navigate a
large chunk of existing Nix code.
Adds the initial version originally published as a gist. This is
already slightly different from the gist in that it contains a section
on derivations.
This is not yet complete.
