-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
gitbutler: init at 0.10.11 #289664
gitbutler: init at 0.10.11 #289664
Conversation
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.
Works quite well 👍 Better than the deb-based package (#289131).
That said, I'm a bit unsure about the bin/gitbutler-app
, where-as the released version is named bin/git-butler
. I couldn't figure out where in the release process this new name is applied, but it might be a good idea to align the Nix output with the released naming. Renaming in fixup could be enough if there is no proper way to do it.
|
||
meta = gitbutler-ui.meta // { | ||
description = "A Git client for simultaneous branches on top of your existing workflow."; | ||
platforms = with lib.platforms; linux ++ darwin; |
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.
Is that an actual limitation of the program, or does it work on any platform which Rust can target (e.g: BSD)?
If the latter, don't set meta.platforms
as buildRustPackage
already sets it to the correct value.
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.
Upstream only claims to support Linux and macOS, so I marked it as such. Is there a precedent for doing otherwise?
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.
platforms = with lib.platforms; linux ++ darwin; |
buildRustPackage already defaults to this
Result of 2 packages built:
|
1 similar comment
Result of 2 packages built:
|
This is permitted according to the license.
This allows backend API requests, such as those needed for logging in, to work.
…xport" This reverts commit e7d5f72d5049bab57d341c0fa8855332fed7a022.
why not?
why? there is already precedent for this in other packages, with the former even being another tauri package using it for the same purpose. i genuinely don't see a reason as to why this shouldn't be used, or how not having standard tooling should force us into dealing with the pretty big maintenance burden (and error prone process) of keeping a lockfile at parity with upstream. if there's a more robust solution that doesn't drastically increase maintenance, i'd love to see it; but having our own lockfile from a different package manager is not it. |
@getchoo for the exact reason explained in the linked issue. If and when This package shouldn't have been approved and merged in that state.
Because when |
this isn't often from my experience with vesktop; seems to be working well in pot as well.
this is very subjective
i would argue the churn required to update the hash is less than or equal to - as the comment in says in the current revision - "[the work required] to test the result thoroughly as dependency versions may differ from the release". we shouldn't be sacrificing the use of upstream's tested set of dependencies for marginal at best productivity gains through only some automation (that hasn't even been implemented) couldn't we also update the FOD hash through an update script? |
I do not think there's much point in discussing the pros and cons of the pnpm technique here - that's why we have #231513 and #290715. Until those discussions are resolved, it does not seem appropriate to copy the contested process once again. I'd prefer to stick with the tried and true Yarn method, despite potential problems arising due to mismatched lockfiles. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/3574 |
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.
Please squash all the reeview comment for each package into the init commit.
distPhase = "true"; | ||
|
||
meta = rec { | ||
description = "The UI for GitButler."; |
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.
description = "The UI for GitButler."; | |
description = "Git client for simultaneous branches on top of your existing workflow"; |
license = lib.licenses.fsl-10-mit; | ||
maintainers = with lib.maintainers; [ hacker1024 ]; | ||
platforms = with lib.platforms; all; | ||
sourceProvenance = with lib.sourceTypes; [ fromSource ]; |
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.
sourceProvenance = with lib.sourceTypes; [ fromSource ]; |
That doesn't need to be set
changelog = "https://github.com/gitbutlerapp/gitbutler/releases/tag/release/${version}"; | ||
license = lib.licenses.fsl-10-mit; | ||
maintainers = with lib.maintainers; [ hacker1024 ]; | ||
platforms = with lib.platforms; all; |
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.
platforms = with lib.platforms; all; | |
platforms = lib.platforms.all; |
meta = rec { | ||
description = "The UI for GitButler."; | ||
homepage = "https://gitbutler.com"; | ||
downloadPage = homepage; |
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.
downloadPage = homepage; |
there is no point in repeating this.
Also this is used wrongly, since it is not a direct link to the download page
let | ||
version = "0.10.11"; | ||
in | ||
assert lib.assertMsg (version == gitbutler-ui.version) "The GitButler version does not match the GitButler UI version!"; |
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.
let | |
version = "0.10.11"; | |
in | |
assert lib.assertMsg (version == gitbutler-ui.version) "The GitButler version does not match the GitButler UI version!"; |
if we inherit the version anyway, then there is not really a point doing this
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 think it might be useful to prevent improper overrides. But the current version will not do that, as you point out.
''; | ||
|
||
postInstall = '' | ||
mv "$out"/bin/{gitbutler-app,'${meta.mainProgram}'} |
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.
mv "$out"/bin/{gitbutler-app,'${meta.mainProgram}'} | |
mv "$out"/bin/{gitbutler-app,'git-butler'} |
a change to meta should not trigger a rebuild
genericName = "Git client"; | ||
categories = [ "Development" ]; | ||
comment = meta.description; | ||
exec = meta.mainProgram; |
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.
exec = meta.mainProgram; | |
exec = "git-butler"; |
desktopName = "GitButler"; | ||
genericName = "Git client"; | ||
categories = [ "Development" ]; | ||
comment = meta.description; |
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.
comment = meta.description; | |
comment = "Git client for simultaneous branches"; |
most DEs don't render so long comments that great
|
||
meta = gitbutler-ui.meta // { | ||
description = "A Git client for simultaneous branches on top of your existing workflow."; | ||
platforms = with lib.platforms; linux ++ darwin; |
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.
platforms = with lib.platforms; linux ++ darwin; |
buildRustPackage already defaults to this
]; | ||
|
||
meta = gitbutler-ui.meta // { | ||
description = "A Git client for simultaneous branches on top of your existing workflow."; |
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.
With my other review comment the description gets already set to this plus it will be compliant with the contributing guide which states that no A in the front or dot at the end should be.
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.
Where is "no A in the front" stated?
https://github.com/NixOS/nixpkgs/tree/master/pkgs#meta-attributes doesn't.
https://nixos.org/manual/nixpkgs/unstable/#var-meta-description even puts a right example with this.
I don't think the A at the beginning caused any problems. In fact, in most cases it even makes the description read more fluently.
nix run nixpkgs#pnpm-lock-export -- --schema yarn.lock@v1 Edit: Oh I'm sorry - I finally saw the comment:
Edit: Updating gitbutler to 0.10.24 fixed the Wayland issue for me. Thanks for working on the package! |
If |
You're right, and it's probably important to match versions especially with the dependencies fetched via git. Unfortunately
When I use
Note that the git hash in the second matches the hash in the original lock file. The
Edit: I found out the esbuild problem comes up because |
It turns out that I updated my PR off of this PR, hacker1024#2, to use the converted lock file. My |
There is a nixpkgs package in progress at NixOS/nixpkgs#289664
@hallettj the current packaged version is a fork by @adamcstephens to support the v6 lock format, feel free to open a PR to update the package if it improves on it in any way. |
Sorry for the long silence, I'll update this PR shortly. Thanks everyone! |
Any updates on this PR? |
Bumping this. |
Hi, @DataHearth has opened a new pr #289664. Do you still want to work on this or prefer their PR instead? |
Hi ! The only prerequisite I need for my PR is someone with a MacOS system to validate the unpack phase. If the current way is not valide, I already have the backup to make it works. For linux, I'm using the appimage. I didn't see any runtime dependencies required for now that wasn't bundled with the appimage (Like jdk for nosql-workbench I've already bundled). I've already tested and used it on x64 linux. Cheers! |
It hasn't been decided to use the source based version instead of the AppImage? |
Generally in Nixpkgs we prefer to build from source where possible. |
So #289664 should be preferred, and hopefully closed shortly. |
# The package.json must use spaces instead of upstream's tabs to pass Nixpkgs | ||
# CI. | ||
# To generate the Yarn lockfile, run `yarn install`. | ||
# There is no way to import the tagged pnpm lockfile, so make sure to test the | ||
# result thoughly as dependency versions may differ from the release. | ||
packageJSON = ./package.json; | ||
yarnLock = ./yarn.lock; | ||
offlineCache = fetchYarnDeps { | ||
inherit yarnLock; | ||
hash = "sha256-rggtkfE6An8It0Rvgfk0J8JHpg0NbLiweRsz0nM/tzM="; | ||
}; |
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.
#290715 👀
Closing in favour of #318101. |
Description of changes
This PR adds a GitButler package that builds from source.
Unfortunately quite a lot needs to be vendored, including the Yarn lockfile (#231513), which needs to be regenerated and may differ from the upstream pnpm lockfile.
Alternative to #289131.
Closes #288567.
macOS is untested as webkitgtk has been broken for years.
If you're interested in maintaining as well, feel free to let me know or make a PR into my branch adding yourself.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.