| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
el_exec: wraps the various execve wrappers in skalib that are useful
for writing execline-like utils. currently only `xpathexec0` is
supported, which execs into the argv you give it or errors with the
right error if file not found.
el_substitute: execline argv substitution! Wraps the execline
function, so it will behave exactly the same as the existing execline
utils, like `importas`.
|
|
|
|
|
| |
We can define a more or less complete generator in less than 50 lines
of nix. Nice.
|
| |
|
|
|
|
|
| |
Less generic, has the spirit of “netstrings, but extended to a
structured encoding format”.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Like a normal `import`, but for dhall files. `importDhall2` can
additionally handle dependencies and additional source files, though
the interface is not stable yet.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Filesystem sandbox around zoom-us.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The haskellPackages attribute is actually part of the package scope
inside pkgs.profpatsch and thus the evaluation fails with the following
error:
attribute 'vuizvui' missing, at .../pkgs/profpatsch/default.nix:176:20
Referencing the attribute directly from within the recursive attribute
set fixes the evaluation error and building dhall-flycheck also
succeeds.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
| |
|
|
|
|
|
| |
It’s the easiest way to get recent statically compiled dhall
executables.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This has been upstreamed to nixpkgs proper, as a C wrapper script, in
https://github.com/NixOS/nixpkgs/pull/71357
So we don’t even need bash to run execline anymore :P
|
|
|
|
|
| |
It previously copied nixpkgs to the store, because a `toString` was
missing.
|
| |
|
|
|
|
|
|
|
| |
`runCommandLocal` was added to nixpkgs in
https://github.com/NixOS/nixpkgs/pull/74642
to speed up trivial `runCommand` derivations by always building them
locally. We have a few places where that’s good to use.
|
| |
|
|
|
|
|
|
| |
Small sandboxing utility, which unshares the filesystem via
user-namespaces and can optionally bind-mount existing paths into the
sandbox.
|
| |
|
|
|
|
|
| |
Minimal PoC of a small application which can download and convert a
youtube video with youtube-dl and then serve it via HTTP.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced in commit e9975c9a39cb4e654d9132de4b952f51174a0926.
The write-execline.nix file is inside the execline/ directory but the
import doesn't reflect that, so since there isn't any write-execline.nix
in other locations, I assume that this is what the author actually
intended.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
|
|
|
|
| |
similar to writeScript, but writes an execline instead. Should be
upstreams to `lib.writers` sometimes.
|
|
|
|
|
| |
A simple way to reference binary paths in an attribute set without
string interpolations everywhere.
|
|
|
|
|
|
|
| |
Earlier, it would just append the execline bin path on every
invocation, which would clobber the path on nested invocations.
We (ab)use the fact that nix paths have a known hash to check whether
it was already added before.
|
|
|
|
|
|
|
|
| |
It’s conventional that these tools have the form
tool name options data
so we should adhere to that.
|
|
|
|
|
| |
We can auto-escape execlines correctly if we model them as nix-style
lists, so we shoud certainly do so. It also helps abstraction.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
A set of utilities to generate and query a git commit index, which is
a database that knows which revs (that is: commits) are in which git
repository. That way we can query for the project that contains a
commit and show them, e.g. with xdg-open.
|
| |
|
| |
|
|
|
|
|
| |
Reference files in `bin` outputs for a derivation as an attribute set,
with renaming capabilities.
|
|
|
|
|
|
| |
Improves the “execline experience” and adds some basic tests.
The idea is that the final result doesn’t use coreutils and provides a
feasible alternative to bash-based tooling.
|
|
|
|
|
|
|
|
|
|
|
| |
* runExecline: like runCommand, but a lot more lightweight
* symlink: symlink a given list of links together
* importer: a small DSL to “import” “modules” into a build context
Some highlights:
* runExecline does not use any stdenv (apart from the `execline` build)
* symlink uses netstrings to pass correct fields into the derivation
* no use of bash, everything uses execline.
|
| |
|
| |
|