drops a git helper git-remote-rad into the users home directory.

Can we get rid of this trough patching?

You mean patching radicle-upstream so it doesn't drop this binary in the home directory anymore?

* the git helper can't publish to the network without the UI running at the moment anyway,

Hej, to clarify: The local state radicle maintains has a certain layout and shape, so whenever you do any git operation on it, it needs some translation which git-remote-rad takes care of. This is independent of publishing to the network which is done by the long-running application process. So the app is disseminating data on the network, the remote helper allows git operations on custom rad remotes.

Let me know if there are other questions about its internals.

From a cursory look, it seems that other packages are building electron apps with something like this:

nativeBuildInputs = [ makeWrapper ];
postInstall = ''
  makeWrapper '${electron}/bin/electron' "$out/bin/application-name" \
    --add-flags "$out/share/path-to-application"
'';

Here's a full example: element-desktop

Could you try building from source using a similar approach? Building from source would be beneficial because it would make this package available for platforms other than x86_64-linux.

I gave a stab at packaging Radicle from source but it's currently not possible because it uses unstable rust features. I have my branch here: https://github.com/adisbladis/nixpkgs/tree/radicle-src.

We should nudge upstream to stop using unstable features and make it possible to compile Radicle with a stable rust compiler.

We should nudge upstream to stop using unstable features and make it possible to compile Radicle with a stable rust compiler.

There's no way to use rust nightly for a package?

Hey sorry, I spaced out on this a little. I've been working on a from source package, I just pushed what I have so far.

There are two issues remaining:

1. as mentioned by @adisbladis, the usage of unstable features in the proxy. I was able to hack around this by using RUSTC_BOOTSTRAP, but I'm not sure if that's considered acceptable or not....
2. Some of the tests are failing in the proxy package, I still wasn't able to figure out what's going on there. If I skip the tests everything seems to work fine (I was even able to submit a contribution using the resulting binary...).

oh, and I also bumped the package to the just released v0.1.5

1. as mentioned by @adisbladis, the usage of unstable features in the proxy. I was able to hack around this by using RUSTC_BOOTSTRAP, but I'm not sure if that's considered acceptable or not....

The unstable features used are very unstable (as in may cause UB on some versions of the compiler), I would be wary of attempting to compile a package using anything other than the exact nightly compiler specified in the rust-toolchain.

2\. Some of the tests are failing in the proxy package, I still wasn't able to figure out what's going on there. If I skip the tests everything seems to work fine (I was even able to submit a contribution using the resulting binary...).

If you share the failing test cases with the exact output I can help shed some light on it.

@xla here, thanks a lot! 🙏 ✨

@midchildan @adisbladis it seems that an appimage build with patched binaries is the way forward here. If you agree I'll revert to that?

Also as a side note I don't understand the ofborg error here, the package builds fine for me locally. What am I missing?

@xwvvvvwx

it seems that an appimage build with patched binaries is the way forward here. If you agree I'll revert to that?

It's ok with me. I appreciate your effort. Could you add also add a comment explaining why source builds are currently not possible with a link to this PR?

Also as a side note I don't understand the ofborg error here, the package builds fine for me locally. What am I missing?

Perhaps the test is attempting a network request?

@xla

Would it be possible to eventually remove unstable rust features? If so, I think it's best if we create a new issue upstream so that we could switch to doing source builds when it's ready.

it seems that an appimage build with patched binaries is the way forward here. If you agree I'll revert to that?

@xwvvvvwx I absolutely agree, let's not let perfect be the enemy of good. We can always fix a source build at a later stage.

pushed a tweaked version of the patched appimage based package.

In this version of the package, I just drop the git-remote-rad helper directly in the users path, meaning they don't need to mess around with shell profiles. This is a nicer experience, but does mean that the prominent instructions in the app to do this are now wrong:

I could also patch the git-remote-rad binary that gets dropped into the home dir, but decided not to since it would make the package a bit messy, happy to change this if people want.

I think having this preinstalled for now is great.
Definitely something that upstream (no pun intended) should expose to packagers to tweak to their liking I'd say. But in my opinion that can wait.

I too think that we should keep it as is. Binary patching should be avoided as much as possible because it would require quite a lot more work to upgrade packages on a regular basis.

This could solved more cleanly by submitting a PR upstream to suppress the message if git-remote-rad is found in PATH.

rebased on master and addressed review comments.

Nice! So exited to test this!