More quality-of-life stuff ...
such as, potentially:
- get commit & source date epoch
- postinstall completions
- set ldflags
{
src = fetchFromGitHub {
owner = "yuzutech";
repo = "kroki-cli";
rev = "v${version}";
hash = "sha256-nvmfuG+i1vw2SZIb1g5mS48uZKnjUgKSN/hip5nY2ig=";
# populate values that require us to use git. By doing this in postFetch we
# can delete .git afterwards and maintain better reproducibility of the src.
leaveDotGit = true;
postFetch = ''
cd "$out"
git rev-parse --short HEAD > $out/COMMIT
# in format of 0000-00-00T00:00:00Z
date -u -d "@$(git log -1 --pretty=%ct)" "+%Y-%m-%dT%H:%M:%SZ" > $out/SOURCE_DATE_EPOCH
find "$out" -name .git -print0 | xargs -0 rm -rf
'';
};
vendorHash = "sha256-HqiNdNpNuFBfwmp2s0gsa2YVf3o0O2ILMQWfKf1Mfaw=";
nativeBuildInputs = [ installShellFiles ];
# ldflags based on metadata from git and source
preBuild = ''
ldflags+=" -X main.commit=$(cat COMMIT)"
ldflags+=" -X main.date=$(cat SOURCE_DATE_EPOCH)"
'';
ldflags = [
"-s"
"-w"
"-X main.version=v${version}"
];
postInstall = ''
installShellCompletion --cmd kroki \
--bash <($out/bin/kroki completion bash) \
--fish <($out/bin/kroki completion fish) \
--zsh <($out/bin/kroki completion zsh)
'';
}
I understand this is hard to maintain, and since these look essentially like workarounds of an non-optimized build* function, hence we might rather need better interfaces in upstream nixpkgs for this.
get commit & source date epoch
This seems like something that should to be integrated into fetchgit. I don't think there is much I can do in terms of determining when this is needed, but I do plan to add some way to pass arbitrary flags to nurl that will make this more customizable.
postinstall completions
It would be hard for nix-init to determine when this is needed, maybe there could be some mechanism to let the user choose extra templates that are not specific to the builder? not exactly sure what I should do here
set ldflags
Sounds like a good idea, might be worth looking into integrating with goreleaser (.goreleaser.yaml)
choose extra templates that are not specific to the builder? not exactly sure what I should do here
If we don't have design clarity, better not do anything, at all.
I wonder how far (teaching) comments could already get us and a final prompt:
Do you want to customize the generated file? (yes)
better not do anything, at all
I agree this should be the default
this is something I have in mind to customize the interactions, note that this is highly theoretical and unpolished
[interactions]
# auto means that nix-init will only prompt when necessary
# default is the preset of what we have right now
base = "default" # "never" | "auto" | "default" | "always"
# the following options will extend the `base`
# all of which will be (true | false | "auto")
# this is the default base
url = "auto"
pname = true
version = true
builder = true
# these are things that could be added in the future
completions = false
man-pages = "auto"
# ...
# these are things that could be added in the future
completions = false
man-pages = "auto"
# ...
These are likely in the competing design space with nixpkgs.
I guess, we'd have to be careful between a "support tool" becoming a "nixpkgs fix".
Implemented detection of ldflags from goreleaser.yml in https://github.com/nix-community/nix-init/commit/06890d706d07eeac4c0792c3bc2413752870ebb1