We were using Pandoc’s Markdown parser. This is non-standard and might cause issues when we finally switch to some other tool.
Since RFC 0072 agreed on CommonMark, let’s switch to that.
We will use some extensions to make the limited syntax bearable but these are official so they should be more portable.
We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly.
Notably:
- Line breaks in lists behave differently.
- Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75
- The auto_identifiers uses a different algorithm – I made the previous ones explicit.
- Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist
While at it, I also fixed the following issues:
- ShellSesssion was used
- Removed some pointless docbook tags.
The patch utility does not understand git formatted patches.
For text files, there is no problem, but binary files use the
git format.
The -a param makes git diff put binary files into the patch in
raw format that can be understood by the patch tool.
Previously it was not possible to define multiple ldflags, since only
the last definition applies, and there's some quoting issues with
`buildFlagsArray`. With the new `ldflags` argument it's possible to do
this, e.g.
ldflags = drv.ldflags or [] ++ [
"-X main.Version=1.0"
]
can now properly append a flag without clearing all previous ldflags.
This change introduces the cargoLock argument to buildRustPackage,
which can be used in place of cargo{Sha256,Hash} or cargoVendorDir. It
uses the importCargoLock function to build the vendor
directory. Differences compared to cargo{Sha256,Hash}:
- Requires a Cargo.lock file.
- Does not require a Cargo hash.
- Retrieves all dependencies as fixed-output derivations.
This makes buildRustPackage much easier to use as part of a Rust
project, since it does not require updating cargo{Sha256,Hash} for
every change to the lock file.
This function can be used to create an output path that is a cargo
vendor directory. In contrast to e.g. fetchCargoTarball all the
dependent crates are fetched using fixed-output derivations. The
hashes for the fixed-output derivations are gathered from the
Cargo.lock file.
Usage is very simple, e.g.:
importCargoLock {
lockFile = ./Cargo.lock;
}
would use the lockfile from the current directory.
The implementation of this function is based on Eelco Dolstra's
import-cargo:
https://github.com/edolstra/import-cargo/blob/master/flake.nix
Compared to upstream:
- We use fetchgit in place of builtins.fetchGit.
- Sync to current cargo vendoring.
To me, as a native English speaker, this doesn't change the meaning of
the sentence at all. But to a non-native speaker, this can read like
the staging-next rules are only recommendations. Let's make this
clearer.
This will ensure the sections have stable links as well as prevent conflicts (pandoc uses heading text for ids and DocBook requires unique ids across the book).
* restore mixBuild
remove bootstrapper by going through ERL_LIBS
mix will use ERL_LIBS to find compiled dependencies
Co-authored-by: Zach <zach@hipcreativeinc.com>
The distinction between the inputs doesn't really make sense in the
mkShell context. Technically speaking, we should be using the
nativeBuildInputs most of the time.
So in order to make this function more beginner-friendly, add "packages"
as an attribute, that maps to nativeBuildInputs.
This commit also updates all the uses in nixpkgs.
Android is deprecating ndk.dir in favor of specifying exact NDK
version in Gradle configuration. Ensure that we can support multiple
NDKs, and link them into the location the Android Gradle Plugin expects.
Describe how to package a plugin that doesn't exist in nixpkgs (and also how to include an external file).
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
It is now possible to pass a `fromImage` to `buildLayeredImage` and
`streamLayeredImage`, similar to what `buildImage` currently supports.
This will prepend the layers of the given base image to the resulting
image, while ensuring that at most `maxLayers` are used. It will also
ensure that environment variables from the base image are propagated
to the final image.
