Change:
Describe the bug Trying to run mutagen results in an error: The mutagen- which is supposed to have binaries for different platforms is missing. To Reproduce mutagen a mutagen session Metadata system: host os: multi-user?: sandbox: version: channels(alex): channels(root): nixpkgs: Maintainer information:
Hey, author of Mutagen here, super excited to see a Nix package for it! I just thought I'd mention that the bundle currently needs to be placed in the same directory as the executable itself. This is something I've been meaning to improve for a while now (by allowing it to be put in a directory), but I haven't had a chance to implement it yet, mostly because it's a little tricky to get right with package managers like Homebrew that symlink binaries into a different target location. I'm not very familiar with Nix, but I'm sure that it would prefer to avoid having this tarball in the directory. So I'm happy to push ahead on trying to support the -based layout if that's helpful here (or perhaps something more general if NixOS prefers a different layout).
cc
A quick update: Mutagen v0.11.2 and later support looking for the bundle in a directory (assuming a Filesystem Hierarchy Standard layout), so a layout of the form: should now work (in addition to the option of installing the bundle directly alongside the executable). This also works in a -style setup where the binary is symlinked into a larger directory.
Thanks! Is the available for direct download?
The bundle ships as part of the official releases (e.g. in the ). It needs to be kept in sync with the version of the binary being installed, but it should work just fine with a binary built locally, so long as the versions are the same (to the patch level). The bundle can also be built locally, but doing so requires running a custom script inside the Mutagen source tree that performs the necessary cross-compilation (this bundle is a collection of cross-compiled binaries that get injected to remote systems to facilitate file synchronization and network forwarding). I'm not sure the best way of handling that in the context of the NixOS packaging system. Perhaps there are some custom hooks available? At the moment, this script doesn't have a flag for building just this bundle (it will only be built as part of a full set of release bundles for all platforms), though I suppose such a flag could be . One of the downsides of doing the cross-compilation locally on Linux (or any non-macOS system) is that the C FFI bindings needed for efficient filesystem watching on macOS won't be available, so file synchronization between NixOS systems and macOS systems will suffer. That might not be a huge loss, though. This is why the Homebrew packages just use the official pre-built release bundles as their "source code." It's a bit non-idiomatic, but it saves on local build times and allows for cross-compiled binaries with C FFI support. Of course, I totally understand if that doesn't work with the NixOS package philosophy, in which case just building the bundle locally is probably the best bet.
As a reference point, here's what the Mutagen Homebrew formula looks like:
I agree, setting up the cross-compilation would not be trivial so the nix derivation must download the prebuilt agents binaries from somewhere while still being able to build the agent on the platform it is running on. I see three possibilities: (No changes on the mutagen side). Nix derivation downloads the full mutagen release and extracts . the version number to the and add it to the downloads. The nix derivation would just download it. the individual downloads for the agents similarly to for all the platforms and have the nix derivation create the itself. That way it would be very easy to even parametrize it to only download the agents the user wants and the nix derivation would supply the binary for the platform it is running on.
All three options are reasonable ideas, though I would prefer to avoid (3) since it would significantly increase the number of assets attached to each GitHub release (which is probably already too high). The individual agent binaries for linux/amd64 that you mentioned are sort of a special case for some experimental container integration features, so I'd prefer to avoid expanding them to every platform. I also don't know if many users want to go through the trouble of filtering the remote platform support that they want, though if that's something users are interested in then I'm certainly willing to try to support that.<sup1</supOption (2) is possible without too much effort, though I don't think it adds much value over option (1). Additionally, if option (1) is already going to be used to download the release bundle, it might as well just pull the binary out of the release bundle as well and save the complexity of a local build. In any case, the current package should have the build of removed since it won't really be of any use. Let me know if option (1) will work and if there's anything I can do to help. <sup1</supI think a better long-term solution is to provide two download variants: a "full" agent bundle that includes all platforms and a "slim" agent bundle that just includes commonly used platforms. P.S. Thanks for helping to support this!
Given the usual problems with pre-compiled binaries, reading the discussion above I thought we might have another problem : nixos needing its own agent in mutagen- But to my surprise, the amd64 binaries work on nixos without the need to patch the ELF interpreter or anything else, it seems that everything is self-contained with no external dependencies. So why not make a binary installation directly?
I can open a brand new issue about this, but wanted to get a quick check from you about a problem I'm having with this. I'm getting the following when extracting an agent: The libexec path appears to be appended to the directory for some reason. I don't know if this is an issue w/ nixpkgs or mutagen but would be happy to help track it down and (maybe) fix it. So, it looks like the file is there, but the search path is treating the absolute path for as if it was relative to the path. I suspect it has to do with the liberal usage of symlinks in nix tripping something up. I'm just too new to golang and nix to have any idea how to fix this.
Hey I believe this is fixed in Mutagen (thanks to who reported it in mutagen-io/mutagen and fixed it in mutagen-io/mutagen). It looks like the corresponding NixOS package needs to be updated — we're currently at Mutagen v0.16.4. If you want to open a NixOS/nixpkgs PR for that, that's probably the way to go. Feel free to @ mention me in that PR, otherwise I'll see if I can find some time to open it during this week.
Thanks for the information. :) I spent some time yesterday trying to get my local system running on Mutagen 0.16.4. I got it working in terms of correctly locating the agents, but I noted in the PR that it isn't working for docker containers because Mutagen running as root does not seem to be able to find Docker installed via nix. I'm happy to move any additional discussion to .

Discussion:
<del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

vendorSha256 = "0szs9yc49fyh55ra1wf8zj76kdah0x49d45cgivk3gqh2hl17j6l"; <ins> agents = fetchzip { name = "mutagen-agents-${version}"; # The package architecture does not matter since all packages contain identical mutagen-agents.tar.gz. url = "https://github.com/mutagen-io/mutagen/releases/download/v${version}/mutagen_linux_amd64_v${version}.tar.gz"; stripRoot = false; extraPostFetch = '' rm $out/mutagen # Keep only mutagen-agents.tar.gz. ''; sha256 = "0k8iif09kvxfxx6qm5qmkf3lr7ar6i98ivkndimj680ah9v1hkj8"; }; </ins> doCheck = false; subPackages = [ "cmd/mutagen" "cmd/mutagen-agent" ]; <ins> postInstall = '' install -d $out/libexec ln -s ${agents}/mutagen-agents.tar.gz $out/libexec/ ''; </ins> meta = with lib; { description = "Make remote development work with your local tools"; homepage = "https://mutagen.io/";