These packages contain the Cloud SDK for Go. There is currently a
linker issue (presumably due to something in `buildGo.nix`) that means
that projects using them can not actually be built.
Usually in large packages the root depends on one or more
sub-packages (or there is no root), but some projects (e.g.
golang.org/x/oauth2) do it the other way around.
This fix adds compatibility for both ways.
This is now a lot more fine-grained than before, but it actually works
fine.
This stuff is a bit annoying to write by hand. There are multiple
different options available (e.g. carrying an attribute set of all
subpackages in each `external` and only passing that, having a tool
generate this, etc.).
Users can supply a list of foreign dependencies in calls to
buildGo.external. These are now appropriately inserted into packages
that *need them* and no further, resolving issues with complex
internal recursion in some repositories!
This error is returned by the build analysis logic if the target
package does not have any relevant Go files, which might be the case
if `+build` flags and such are used.
Changes in the structure of buildGo.external meant that the package
layout for the protobuf library is now slightly different.
`proto` has been amended to work with the new structure. Callers of
buildGo.proto do not need to be updated (i.e. the example still
works).
Implements a builder function that calls the analysis tool on the
provided source and builds up the required attribute set, including
local dependencies.
Fixes the prefix trimming logic for package names and source files if
the source files appear in the package root (which is, unsurprisingly,
very common).
Due to the lexical walk order of `filepath.Walk` the previous
directory identification logic failed under certain conditions if the
top-level directory contained Go files that showed up *after* the
first subdirectories.
To simplify the logic a set of directories is now gathered instead on
a file-level.
Sub-packages of external dependencies are traversed by Nix as a tree
of attribute sets which need to be accessed by "path". To make this
easier, the dependency analyser now returns "paths" as string lists.
Adds a tool that can analyse dependencies that were not originally
meant to be built with buildGo.nix and return information that can be
used to construct appropriate Nix dependencies.
The tool will return information about package-local and foreign
dependencies separately to let Nix determine whether all required
dependencies are provided and to correctly link together sub-packages.
To avoid listing standard library imports in the dependencies, a list
of all packages in the standard library is generated statically to
allow for those to be filtered out during the analysis.
This tool is still work-in-progress.
Adds an alternative implementation of a builder for external packages
which traverses packages and builds up an attribute set tree out of
their structure.
Currently this is not functional because there is no useable method of
specifying dependencies within that package set.
Sometimes things that get imported are (intentionally) not attribute
sets, e.g. for build functions.
Those should not be merged with the marker because, well, that's not
possible.
Rewrites the previous initial tick-tocking recursion into a more
straightforward style.
Every attribute set that is imported by readTree now also contains an
attribute called `__readTree` set to `true` which acts as a marker for
other types of tree traversals.
Unfortunately directories without any children or importable content
still result in empty attribute sets, but overall this might be the
better tradeoff vs. having to follow the recursion all the way at each
subtree level to determine which children exist.
Adds a `__treeChildren` attribute that is set to `true` on derivations
that have children, e.g. for cases where a folder contains a
`default.nix` but has subdirectories with additional things in them.
Instead of polluting the repository namespace with the list of CI
projects, move that to a separate file.
Currently the list of projects to be built by CI is still hardcoded,
but this will be fixed soon.
If a folder contains a `default.nix`, Nix expressions contained in
adjacent files should not be imported (they might be things like a
`shell.nix` or a `deps.nix` which do not evaluate to derivations).
The tree traversal still continues for all children folders of a
folder with a `default.nix`.
Instead of exposing the entire package tree from nixpkgs, whitelist
individual packages explicitly so that they show up in
`pkgs.third_party`.
This makes it much easier to control external dependencies used by my
projects.
Bonus: It even includes a working `third_party.callPackage` with only
the whitelisted packages!
This is not the final layout yet, but makes it so that my top-level
attribute set is no longer overlaid into nixpkgs itself.
This is useful for other people who are importing my monorepo.
This makes it possible to override arguments to the Go builders
downstream in the style of `overrideAttrs` from standard nixpkgs
derivations.
For example, given a Nix value `foo` that builds a binary called `foo`
the name of this binary could be changed and a new dependency on
`somelib` added like so:
foo.overrideGo(old: {
name = "bar";
deps = old.deps ++ [ somelib ];
})
This makes it possible for people to drop a default.nix into folders
along the way that add additional things into the attribute set at
that level.
These default.nix files are imported and merged with the rest of the
traversal from that point on. In theory nothing stops a user from
putting a derivation into one of them, but the effects of merging that
derivation's underlying attribute set with random other things from
the traversal are undefined.
This feature is being introduced for a slight revamp of the thirdParty
layout.
