New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gup: 0.5.5 -> 0.6.0 and extract src into JSON #21516
Conversation
@timbertson, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nckx to be a potential reviewer. |
@@ -0,0 +1 @@ | |||
src.json.gup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And what's in src.json.gup
and does it make sense not to commit it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at this point - it's just:
#!bash -eu
update_script="$(which nix-prefetch-src)"
gup -u src.in.json "$update_script"
"$update_script" src.in.json "$1"
..which relies on a script in https://github.com/timbertson/app-customisations/ being on $PATH
. One day I might package it for easy public use, but I haven't put in that effort yet.
..which relies on [a script](https://github.com/timbertson/app-customisations/blob/master/bin/nix-prefetch-src) in https://github.com/timbertson/app-customisations/ being on `$PATH`. One day I might package it for easy public use, but I haven't put in that effort yet.
What about just putting it into `maintainers/scripts/timbertson/nix-prefetch-src` and calling it via a relative path?
I think right now NixPkgs has exactly one instance of `.gitignore` (at the top level) and I am not sure I want to change that…
|
So Is |
Oops, not anymore. Removed, thanks.
Actually the opposite - I've been thinking this sort of scheme might be widely applicable for scriptable updates, so I'd eventually like it to support all kinds of repos (aided by a |
if [ -n "${GUP_TARGET:-}" ]; then | ||
gup --always | ||
fi | ||
curl -LSs -o "$1" https://raw.githubusercontent.com/timbertson/gup/master/nix/gup-python.nix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you combine master
version of build.nix
with latest-release source version? Isn't that going to break?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could possibly do something more complex to get the branch that's just been updated, but practically speaking I'll always be updating to the latest release. If I ever need to update to an old release for some reason, I'd have to fix this up (although the .nix file doesn't change that much between versions anyway, so it still might not matter)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, if you commit to always prevent «master
contains build.nix
for the future release, not for the current» as the maintainer on both sides, then I guess that's acceptable.
passthru = { | ||
updateScript = '' | ||
set -e | ||
echo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update.nix
which runs the updateScript doesn't print a newline before invoking the script, but this update script wants its own line (since it prints a prompt)
updateScript = '' | ||
set -e | ||
echo | ||
cd ${toString ./.} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, this does work? nice…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was pretty surprised, but yes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(well, as long as you're building it from a checkout ./default.nix
, not <nixpkgs>
- that probably wouldn't work)
(well, as long as you're building it from a checkout `./default.nix`, not `<nixpkgs>` - that probably wouldn't work)
Did you try `<nixpkgs>` when it is the full checkout that happens to be in `$NIX_PATH`?
|
Yep, that works too. It just doesn't work if you're using the channel instead of a git checkout, since that's always going to live in /nix/store. |
Well, running an updater without having a checkout doesn't make too much sense anyway. |
Motivation for this change
fetchFromGitHub
attributes into separate JSON file for scripted updatesThings done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)