| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Initial code that fetches a youtube playlist (from ID) and converts it
to an rss feed.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
If we sandbox each run of our youtube-dl script inside of the UCSPI
TCP server, we get a temporary directory “for free”, plus guarantees
that the files are cleaned up after the process exits.
|
|
|
|
|
|
| |
EXECLINE_STRICT does not apply to the `execlineb` command itself, so
we don’t get any errors if the nesting is incorrect. `-W` does set it
for `execlineb` however.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First working mockup of a dhall Haskell API that can read files of
the (normalized) form
```
\(CustomType: Type) ->
\(AnotherType: Type) ->
…
```
and set their actual representation on the Haskell side.
This has various advantages:
- dhall files still type check & normalize with the normal dhall
tooling, they are standalone (and the types can be instantiated from
dhall as well without any workarounds)
- It can be used like the default `input` function, no injection of
custom symbols in the Normalizer is reqired
- Brings this style of dhall integration to Haskell, where it was only
feasible in nix before, because that is untyped
The dhall types can be instantiated by every Haskell type that has an
`Interpret` instance. The “name” of the type lambda variable is
compared on the Haskell side with a type-level string that the user
provides, to prevent mixups.
TODO:
- Improve error messages (!)
- Provide a way to re-use the type mapping on the Haskell side, so
that the returned values are not just the normal `Interpret` types,
but the mapped ones (with name phantom type)
|
| |
|
| |
|
|
|
|
| |
The battery life is displayed as an [sft] timespan.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
First version of a way to build s6 services using `dhall-to-nix`.
Includes a small library that formalizes the tables in `man 7 signal`.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The build currently fails on Hydra and I highly doubt that it will be
used on an i686-linux system. If it's really needed for i686-linux
systems it can be directly used for a specific machine or this very
commit could be reverted.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|