-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
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
dstask: init at 0.18 #87383
dstask: init at 0.18 #87383
Conversation
Please also add yourself to https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix |
Please consider building from source instead. Go packages should be rather easy to package, see https://nixos.org/nixpkgs/manual/#sec-language-go |
@symphorien Thanks for responding. I'm giving it a shot. Here's my current attempt:
When running
I don't understand why it's trying to fetch "https://github.com/naggie/dstask/archive/{$version}.tar.gz" instead of "https://github.com/naggie/dstask/archive/0.17.tar.gz". Could you give me a pointer? |
I think you meant About hashes, replace them with zeroes, and nix will give you the right hash in the error message. |
Thanks! I now tried this:
Here's what happen when I build and look in the result directory:
Note the |
Honestly, I'm not very familiar with go. Maybe we can wait for someone more knowledgeable or you can ask on irc or on discourse ? |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/help-building-a-go-package/7117/1 |
Thanks again @symphorien . I've asked for help on the nixos discourse. |
Thanks to foxit64 here the build now works! |
The build error says:
I tried building locally just using
Does that mean that |
@stianlagstad |
Looking at go-modules/generic/default.nix I saw this recent change. I've updated the PR to use |
I see that these two checks fail with:
That's from this part of the nix expression:
I don't understand enough of this yet to know what to do. @naggie are you able to assist? |
I think I vendor the modules to make sure it's possible to build dstask even if the thirdparty dependencies are removed/changed from github. |
Also I wonder if we need to add |
@naggie Thanks! Looks like I messed up that build flag in my change though. The build log of the new failure:
(from https://logs.nix.ci/?key=nixos/nixpkgs.87383&attempt_id=617729ef-59b3-437b-af72-45c4176daa3f) |
I think that needs its own new line, else it's probably parsed as an ldflag:
(a guess -- I've not had time to get nix/nixos running) |
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.
LGTM
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.
LGTM 👍
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review-may-2019/3032/172 |
squashing/rebasing the commits into 2 would be 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.
Sorry for holding this up even longer, but there are a few things I would like to see clarified. Its important to document everything as well as possible in the expression itself, since the next person looking at it will not have the context you have right now (even if the next person is you).
I think we're close to the finish line though. Once you have made all the changes, please squash your commits so that only two remain:
maintainers: add stianlagstad
dstask: init at 0.18
(in that order). Note that the format of the maintainers commit message needs to be amended and the version in the init commit needs to be changed to 0.18.
If you're not familiar with the workflow, have a look at https://about.gitlab.com/blog/2018/06/07/keeping-git-commit-history-clean/ (situation 3).
Looking forward to merging this :)
No problem, I'm glad the standards are so high |
I've updated the commits now. Thank you all for the help so far, and please do feel free to comment further as I'm in no particular rush and would like to follow the standards. |
-X "github.com/naggie/dstask.VERSION=v${version}" | ||
-X "github.com/naggie/dstask.GIT_COMMIT=${rev}" |
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.
How about this:
-X "github.com/naggie/dstask.VERSION=v${version}" | |
-X "github.com/naggie/dstask.GIT_COMMIT=${rev}" | |
-X "github.com/naggie/dstask.VERSION=${version}" | |
-X "github.com/naggie/dstask.GIT_COMMIT=v${version}" |
I don't see why there should be a v
prefix for the version. At the same time, v${version}
is the name of the tag and therefore a valid specifier of a git commit.
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.
Seems like a good change as it would keep the output of dstask version consistent with the official binary, which currently outputs:
Version: v0.18
Git commit: d687a0f9aec634a808cfa0df4aecb06ab4f57732
Build date: Wed 13 May 18:34:38 BST 2020
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.
Thank you both again! I've updated the PR.
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.
@naggie it sound like you may be reading the diff the wrong way around. Previously it would have output
Version: v0.18
Git commit: d687a0f9aec634a808cfa0df4aecb06ab4f57732
but now it should be
Version: 0.18
Git commit: v0.18
The reasoning behind this is that we would like to avoid having to manually set the fully-qualified git revision of the release in our expression. That would be cumbersome and our automated tooling wouldn't update that. At the same time, since the version is tagged v0.18
is also a valid reference to the git revision.
We've dropped the v
prefix from Version
since 0.18
is the version number while v0.18
is the name of the tag.
Is that fine by you?
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.
Looks good to me now, except that one line and pending approval of @naggie regarding the version/rev setting.
Thank you to: foxit64, naggie, timokau, Lassulus, 06kellyjac, symphorien, wamserma.
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.
Looks great to me now. I'll merge this if and when @naggie approves. If I forget about this, please ping me again some time next week.
Thanks everyone for your patience and responsiveness. I think the end-result is a high-quality package. I'll probably check it out some time, I have even thought about working on a taskwarrior alternative myself already. Welcome to the team @stianlagstad 🎉 |
Great, thanks to everyone, really appreciated! I'm new to nix, I assume it will end up in nix-unstable after the build server grabs it? |
Pretty much. The build server periodically grabs the latest nixpkgs revision and builds all packages. Once that is done and some checks pass, the You don't have to wait for that though. Nix makes it possible to build packages or even your whole system from any nixpkgs checkout, it doesn't have to be a channel. The packages that have already been built will transparently be pulled in from the binary caches, everything else will be built from source. Imagine a blend of ArchLinux and Gentoo. The point of channels is mostly to signal everyone "the binary channel for this revision is populated and the tests have passed". |
Oh I see, I like the sound of that. I prefer this to the AUR due to the review process, and the fact there's the binary cache means things are fast where possible. |
Congratulations to @stianlagstad for your first successful merge! Thanks to everyone! |
Thank you everyone for the help! In case anyone else stumbles upon this and wants to install dstask before its available in a channel (i.e. me a little while ago): See Adding Custom Packages in the NixOS manual. |
Cool, it's now listed: https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=dstask |
Motivation for this change
I'd like to still use https://github.com/naggie/dstask after switching from Ubuntu to NixOS.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)