* buildGoModule: don't inherit postBuild hook when building go-modules
This is a slight revert of 5ce647b8bf
(#212800).
Inheriting these hooks in the `.go-modules` derivation can be confusing:
One doesn't expect them to run when generating the fixed output modules
derivation, but only on the main derivation. A `postBuild` hook that
adds some files to $out will cause a very hard to debug issue[1].
This commit adds support for a dedicated `modPostBuild` hook that will
be used only by the derivation building `.go-modules`. Additionally,
`go.section.md` now explains these attributes behavior better.
[1]:
https://discourse.nixos.org/t/cant-update-a-go-package-getting-go-inconsistent-vendoring/27063/6
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Some Flutter packages require additional attribute values to be added to buildFlutterApplication, to add things like libraries and environment variables.
To prevent duplication in applications that use the packages, a repository of package overrides is kept. buildFlutterApplication will look for package overrides for each dependency, and apply them by calling overrideAttrs on itself.
This allows thing like `flutterBuildFlags` and `runtimeDependencies` to be overridden with `overrideAttrs`.
Attributes that affect dependency retrieval cannot be overridden.
This uses `dart pub deps` (https://dart.dev/tools/pub/cmd/pub-deps) to retrieve information about project dependencies.
It requires a fetch-dart-deps derivation as input.
This wraps Flutter programs with an appropriate LD_LIBRARY_PATH.
For some reason, the RUNPATH of the executable is not used to load dynamic libraries in dart:ffi with DynamicLibrary.open().
This could alternatively be fixed with patchelf --add-needed, but this would cause all the libraries to be opened immediately,
which is not what application authors expect.
The name of the runtimeDependencies argument was chosen to match autoPatchelfHook, which has a similar feature.
This reduces the size of the executable.
It works well with Nix - if the user includes the version in their bug report, the exact debugging symbols required can easily be found.
88275ca6d6 inadvertently stopped the pubspec.lock from changing, as it copied the file before running pub get.
pub get can modify the pubspec.lock to update it to newer formats (for example by adding hashes and updating URLs, see an example diff below). We do not need the modifications at any later stage, so we can preserve the original file.
boolean_selector:
dependency: transitive
description:
name: boolean_selector
+ sha256: "6cfb5af12253eaf2b368f07bacc5a80d1301a071c73360d746b7f2e32d762c66"
+ url: "https://pub.dev"
- url: "https://pub.dartlang.org"
source: hosted
+ version: "2.1.1"
- version: "2.1.0"
Pub does not perform any Git operations on the cached package directly, instead cloning it through a mirror.
The .git directories are not needed, and are a source of non-determinism.
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
The dependency fixed-output derivation now uses the recursive hash mode to avoid tarballing and copying all the files.
https://github.com/NixOS/nix/issues/6660 was ran into during the development of this change. Input references were found in the Git package cache before nukeReferences was used.
It turns out that the mirrors in the Git package cache do not actually need to be preserved, as the SDK does not use them during the build process. They are therefore deleted in the dependency derivation and re-created as blank repositories in the main derivation.
A description of the Git package cache layout can be found here: c890afa1d6/lib/src/source/git.dart (L339)
Files and directories such as .dart_tool, .flutter-plugins, .packages and .pub-cache/hosted/*/.cache will be happily regenerated by the SDK in an offline environment.
The patches being made to these files and directories to remove non-determinism were flawed: They did not handle cases where files only appeared in one run, or cases where tooling versions had an effect on the output.
While this may be beneficial for packages that ship native binaries, this causes issues due to Flutter packages that have inappropriately uploaded build artifacts (such as those from example subprojects) to pub.dev.
