This was based off fetchzip, but unlike fetchzip we don't need to
support arbitrary archive formats, so we don't actually need the unpack
hooks.
Change-Id: I5655c031f420422f13e72bb79f4b4b95f6f1204e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1640
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Reviewed-by: tazjin <mail@tazj.in>
This removes the need for `map (x: x.gopkg)` in dependency lists.
Change-Id: Ia19e51f14110bf22f5cdbb64fa7ce182e1b34241
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1624
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This makes the derivations more uniform, since both third-party
packages generated by buildGo.external and native buildGo.package
expose their libraries as gopkg attributes now.
Change-Id: I547f9860082f36e3300139bf67613eb4fc600d24
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1623
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Add support for explicitly specifying tests as part of a buildLisp
program or library.
Change-Id: I733213c1618f0fa60f645465560bce0522641efd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1481
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This was already happening for libraries, but not for programs - as a
result, programs built with libraries that contained unicode (eg
cl-unicode, uax-15, ...) would fail to build due to character encoding
issues when loading the FASLs.
Change-Id: I66149b585e85b213d0c026153140a1925536bd29
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1469
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Without this, we would end up with "double" store paths like this:
/nix/store/848js1fvbjniv5n00hifmhgzzszl97vv--nix-store-ad6piq18wdkxnfzsbyn88ixvv7gfb1dp-main.go.drv
We really only care about the `main.go` bit though.
Change-Id: Ib0644781a0e232a45e1cae3dd05b9b828c9087ee
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1321
Tested-by: BuildkiteCI
Reviewed-by: ericvolp12 <ericvolp12@gmail.com>
Breaking change detection will run but not enforce.
Emoji of water buffalo was chosen by @pedge fiat in the bufbuild slack.
Change-Id: Ie292f2bfddc0e3bc512e4a138c0b5d0fa2603bad
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1247
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: glittershark <grfn@gws.fyi>
If you compiled dirA/test.lisp and dirB/test.lisp in the same library,
they'd both get written to /test.fasl and the second would overwrite the
first. Instead, use the whole store path (with / swapped for -) as the fasl
filename.
Change-Id: I4eb88b5d33757751e1f67e72ed328bd58079b1b9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/944
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
We have this nice `runExecline` now, so we don’t need to use
`runCommand` (which spawns bash) just to write a simple script.
Change-Id: I2941ed8c1448fa1d7cc02dc18b24a8a945b2c38b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/704
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: BuildkiteCI
runExecline is a primitive that just does not care.
It’s similar to `runCommand`, but instead of concatenating bash
scripts left and right, it actually *uses* the features of
`derivation`, passing things to `args` and making it possible to
overwrite the `builder` in a sensible manner.
Additionally, it provides a way to pass a nix string to `stdin` of the
build script.
Similar to `writeExecline`, the passed script is not a string, but a
nested list of nix lists representing execline blocks. Escaping is
done by the implementation, the user can just use normal nix strings.
Change-Id: I890d9e5d921207751cdc8cc4309381395d92742f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/701
Reviewed-by: BuildkiteCI
Reviewed-by: isomer <isomer@tvl.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
The escaping functions are going to be used by both `writeExecline`
and `runExecline`, so let’s move them to their own namespace.
Change-Id: Iccf69eaeca3062573e0751a17c548b7def86196d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/706
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Kane York <rikingcoding@gmail.com>
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.
