Mac Application launchers not symlinked on darwin

[starcraft66]

Issue description

I noticed that when I install an application on macOS that includes a GUI launcher (emacs in my case) using nix-darwin, Emacs.app is symlinked into ~/Applications/Nix Apps so that things like Spotlight can find and launch Emacs without requiring me to have a dedicated terminal open to start emacs.

I think home-manager should adopt this behaviour and symlink its apps into ~/Applications/Home Manager Apps or something like that to greatly improve the experience of launching GUI apps on macOS/darwin.

Meta

Not sure what other useful information to add, this is more of a feature request than a bug.

[starcraft66]

I should add that applications are already symlinked into ~/.nix-profile/Applications by nix-env(?) but this is not enough for them to be picked up by Spotlight. nix-darwin goes a step further by linking these apps into ~/Applications where Spotlight does search for apps.

https://github.com/LnL7/nix-darwin/blob/master/modules/system/applications.nix

[berbiche]

Here's what I added to my configuration to make this work

EDIT : the example has been further simplified

{
  # Install MacOS applications to the user environment if the targetPlatform is Darwin
  home.file."Applications/home-manager".source = let
  apps = pkgs.buildEnv {
    name = "home-manager-applications";
    paths = config.home.packages;
    pathsToLink = "/Applications";
  };
  in mkIf pkgs.stdenv.targetPlatform.isDarwin "${apps}/Applications";
}

[berbiche]

This task is now handled in my PR #1460

[jwiegley]

I'm seeing a conflict between the above code and nix-darwin:

Creating home file links in /Users/johnw
ln: failed to create symbolic link '/Users/johnw/Applications/Home Manager Apps': Permission denied

This is because ~/Applications is a symlink into my Nix store that cannot be modified, while it looks like home-manager is trying to make a new directory directly within ~/Applications.

[berbiche]

You are right. The logic in nix-darwin to symlink applications to ~/Applications is here.

if [ ! -e ~/Applications -o -L ~/Applications ]; then
    ln -sfn ${cfg.build.applications}/Applications ~/Applications
elif [ ! -e ~/Applications/Nix\ Apps -o -L ~/Applications/Nix\ Apps ]; then
    ln -sfn ${cfg.build.applications}/Applications ~/Applications/Nix\ Apps
else
    echo "warning: ~/Applications and ~/Applications/Nix Apps are directories, skipping App linking..." >&2
fi

AFAIK there are many applications that create folders within ~/Applications so nix-darwin's logic seems wrong.
The first if should be removed altogether.

Maybe @LnL7 could provide more input?

[rycee]

@jwiegley Is it nix-darwin that takes ~/Applications or something else? I don't know macOS so I assumed that ~/Applications is a pre-existing directory for all users. I guess that assumption is wrong? Should I revert the d3aee54 commit?

[berbiche]

On a brand new Mac ~/Applications already existed in my case

[rycee]

I've disabled the feature in the above commit until we've come to an agreement with nix-darwin 🙂

[Atemu]

I don't see a reason why this should also be disabled for Darwin users who don't use nix-darwin, could you make it an option instead?

[nuance]

I might have something unusual about my setup, but I've found that symlinks don't get picked up by spotlight, so symlinking the app dir (or the individual apps) don't cause them to show up in my spotlight search (eg cmd-space + "emacs" only shows web results).

After some debugging, I found that spotlight ignores symlinks but will index aliases. Aliases are kind of awful to work with - you can't seem to create them from the CLI without pinging finder via AppleScript / osascript.

I've added the following to my config which seems to make things work:

  home.activation = {
    aliasApplications = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
      app_folder=$(echo ~/Applications);
      for app in $(find "$genProfilePath/home-path/Applications" -type l); do
        $DRY_RUN_CMD rm -f $app_folder/$(basename $app)
        $DRY_RUN_CMD osascript -e "tell app \"Finder\"" -e "make new alias file at POSIX file \"$app_folder\" to POSIX file \"$app\"" -e "set name of result to \"$(basename $app)\"" -e "end tell"
      done
    '';
  };

(in the context of my dot files: https://github.com/nuance/dotfiles/blob/master/nix/environments/macos.nix#L11-L19)

Happy to make a PR for this or let someone else use this code if it looks reasonable.

[Atemu]

An alternative solution I have (sort of) working locally is to cp -r --symlink the .Apps or maybe even just symlink the Contents/ subdir but at least one app (Anki) has issues with that approach.

[wmertens]

I don't have a Mac any more, but isn't it sufficient to symlink from ~/Applications/Nix Apps to ~/.nix-profile/Applications?

[Atemu]

It is not. As @nuance mentioned, Finder ignores symlink for whatever stupid reason.

Although you could try aliasing the whole directory instead of the indiviual apps perhaps.

[nuance]

For what it’s worth, wasn’t able to figure out how to alias a directory with applescript, but I’m barely proficient at it so it’s possible I’m missing something simple. Aliasing the folder definitely seems a little cleaner and deals with removing applications, which my solution currently does not (the alias will point to whatever previous install exists, which might cause interesting behavior in the event nix GCs it...).

…

On Tue, Jan 19, 2021 at 1:58 PM Atemu ***@***.***> wrote: It is not. As @nuance <https://github.com/nuance> mentioned, Finder ignores symlink for whatever stupid reason. Although you could try aliasing the whole directory instead of the indiviual apps perhaps. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1341 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACBDAXV4SEIBOL5CGJ2L3S2XI3VANCNFSM4OCG3S7A> .

[midchildan]

I'm guessing that people who're having problems with Spotlight installed Nix using the post-Catalina installer. The newer installer creates the Nix store on a separate filesystem, which prevents files there from being indexed by Spotlight.

There are 2 known solutions for this:

1. Make Spotlight index the Nix store and continue to use symlinks
2. Create aliases to individual applications

However, there are problems with both one way or another. The same issue came up on Homebrew numerous times, and they never found a satisfactory answer.

[midchildan]

With the symlink approach, things should work just as it did before. However, I haven't upgraded from Mojave, so I can't be 100% sure whether it would work on Catalina and later. But the problem is, Spotlight will pick up all applications from the Nix store and not only the ones in the current profile. This means it's very difficult to tell which one to choose when you have multiple profile generations in your Nix store:

With the alias approach, you won't have the same problem as long as the Nix store is out of reach of Spotlight. However, the alias won't be categorized under "Applications" and will get pushed far down the list:

Comparing the two, the alias approach slightly looks more usable if it turns out to work reliably. There are past reports of the "right click → Open With" functionality not working when using the alias approach, but I haven't encountered that problem so far so it may have been resolved.

Looking at Homebrew's past struggles with aliases, the main issue seemed to be about keeping aliases in a healthy state between upgrades. Home Manager might not suffer from this problem because it can delete the Home Manager Apps directory and recreate the aliases from scratch on each upgrade. I don't know how reliable this will be when the aliases cross filesystem boundaries though.

[Atemu]

FWIW, I've been using the cp -rs approach for Emacs successfully and maybe it's just Anki for which it doesn't work (I don't manage any other apps with Nix).
I've got an experimental branch here but it might not work in some cases because --no-preserve=mode strips exec permission too. I wanted to find a way to only reset the write permission but you could also just chmod +w afterwards I guess.

If it turns out that doesn't work with many other apps, we could also resort to just copying the .apps. (hard- or reflinks would be cross-device unfortunately.)

[midchildan]

I've just tried the cp -rs approach, but it appears spotlight won't index those too. The apps would appear on Launchpad and you can launch them alright, but it won't appear on spotlight searches.

Here are the steps I followed to check:

1. Remove all instances of MacVim from paths indexed by Spotlight
2. Download the official DMG for MacVim
3. Open the DMG image
4. Run nix run nixpkgs.coreutils -c cp -rs /Volumes/MacVim/MacVim.app ~/Applications
5. Open Spotlight (Cmd + space) and search "MacVim"

MacVim.app is symlinked from the DMG image to simulate the post-Catalina situation in which the Nix store resides on a separate filesystem.

Copying the apps could be tricky as well because if I understand correctly, apps built in nixpkgs have no guarantee of being relocatable.

[Atemu]

Yeah doing it with MacVim doesn't work for me either. Weird that it does work for Emacs though.

[nicknovitski]

Currently I copy the applications, and it's working for me so far. cp -fHRL resolves all symlinks, and though the copied apps may have references to files in the nix store, those won't be garbage collected as long as the "original" applications are still in the current profile.

  home.activation = {
    copyApplications = let
      apps = pkgs.buildEnv {
        name = "home-manager-applications";
        paths = config.home.packages;
        pathsToLink = "/Applications";
      };
    in lib.hm.dag.entryAfter [ "writeBoundary" ] ''
      baseDir="$HOME/Applications/Home Manager Apps"
      if [ -d "$baseDir" ]; then
        rm -rf "$baseDir"
      fi
      mkdir -p "$baseDir"
      for appFile in ${apps}/Applications/*; do
        target="$baseDir/$(basename "$appFile")"
        $DRY_RUN_CMD cp ''${VERBOSE_ARG:+-v} -fHRL "$appFile" "$baseDir"
        $DRY_RUN_CMD chmod ''${VERBOSE_ARG:+-v} -R +w "$target"
      done
    '';
  };

I think if home manager were to change to handle this use case, it might add an option for copying targets rather than linking them, but how could it do this safely? It would need to be able to overwrite targets that already exist.

[Atemu]

Like this?

https://github.com/Atemu/home-manager/blob/darwin-copy-apps-fully-wip/modules/targets/darwin.nix

I'm not sure how well reverting back to a symlink could work but atm HM just says the dir is in the way of the symlink and needs to be removed first which I think is fine.

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[magikid]

I'm using the aliasing approach and needed to make a small change to get apps with spaces in their names working properly. I update the IFS to not care about spaces.

        home.activation = {
            aliasApplications = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
                ORIGIFS=$IFS
                IFS=$'\n\t'
                app_folder=$(echo ~/Applications/Home\ Manager\ Trampolines);
                for app in $(find "$genProfilePath/home-path/Applications" -type l); do
                    echo "Linking $app to $app_folder"
                    $DRY_RUN_CMD rm -f $app_folder/$(basename $app)
                    $DRY_RUN_CMD /usr/bin/osascript -e "tell app \"Finder\"" -e "make new alias file at POSIX file \"$app_folder\" to POSIX file \"$app\"" -e "set name of result to \"$(basename $app)\"" -e "end tell"
                done
                IFS=$ORIGIFS
            '';
        };

[pshirshov]

Better version with mkalias:

  # don't forget to add 'com.apple.alias-file' without quotes into alfred's Extras
  home.activation = {
    aliasHomeManagerApplications = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
      app_folder="${config.home.homeDirectory}/Applications/Home Manager Trampolines"
      rm -rf "$app_folder"
      mkdir -p "$app_folder"
      for app in $(find "$genProfilePath/home-path/Applications" -type l); do
          app_target="$app_folder/$(basename $app)"
          real_app="$(readlink $app)"
          echo "mkalias \"$real_app\" \"$app_target\"" >&2
          $DRY_RUN_CMD ${pkgs.mkalias}/bin/mkalias "$real_app" "$app_target"
      done
    '';
  };

[Tobix99]

@pshirshov I had some problems with your script with VS Code (because of the spaces in the "file name")

I updated it to this:

home.activation = {
  aliasHomeManagerApplications = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
    app_folder="${config.home.homeDirectory}/Applications/Home Manager Trampolines"
    rm -rf "$app_folder"
    mkdir -p "$app_folder"
    find "$genProfilePath/home-path/Applications" -type l -print | while read -r app; do
        app_target="$app_folder/$(basename "$app")"
        real_app="$(readlink "$app")"
        echo "mkalias \"$real_app\" \"$app_target\"" >&2
        $DRY_RUN_CMD ${pkgs.mkalias}/bin/mkalias "$real_app" "$app_target"
    done
  '';
};

[pshirshov]

Anyway, linking is broken. It's better to just make copies: LnL7/nix-darwin#214 (comment)

[hraban]

Anyway, linking is broken. It's better to just make copies: LnL7/nix-darwin#214 (comment)

Copying has been discussed upthread and it's less reliable in the wild than creating a link of some kind (whether symlink, trapoline, alias, ... is up for debate). There isn't a clear winner so far.

[remi-gelinas]

Is this still actually an issue? I haven't done anything specific in my config to link application files, for home-manager or nix-darwin, and both seem to be linking application bundles correctly

[hraban]

Is this still actually an issue? I haven't done anything specific in my config to link application files, for home-manager or nix-darwin, and both seem to be linking application bundles correctly

Spotlight and Launchpad (usually) don't pick up on apps inside a symlink inside the application directory. Support for Spotlight is nice when you want keyboard-only navigation without any external tools, just ⌘-space <first few letters of app name> RET

[remi-gelinas]

Spotlight and Launchpad (usually) don't pick up on apps inside a symlink inside the application directory. Support for Spotlight is nice when you want keyboard-only navigation without any external tools, just ⌘-space RET

Right - but is that something HM can actually fix, or is that a spotlight issue?

[pshirshov]

There are reasonable workarounds.

[hraban]

Spotlight and Launchpad (usually) don't pick up on apps inside a symlink inside the application directory. Support for Spotlight is nice when you want keyboard-only navigation without any external tools, just ⌘-space RET

Right - but is that something HM can actually fix, or is that a spotlight issue?

That's what this thread is about :) welcome to the jungle.

[krad246]

From my experience your solution has been working fine @hraban . Ideally yeah just to keep a single source of truth you'd want a mount or some kind of symlink, etc. but trampolining it feels pretty unobtrusive as it stands. I haven't noticed any weird stuff.

[remi-gelinas]

Interesting... So for example, Raycast can find the symlinks that Home Manager and nix-darwin create by default. If I understand correctly, Spotlight normally can't see those, and requires extra trampolines? With @hraban's solution for aliasing, will Spotlight find those trampolines?

[rrittsteiger]

Symlinks don't work from my experience. Aliases are the way to go. From Apples point of view, I would assume, that this is not a bug but a feature. Would be great if there would be a possibility in HM to fix this.

[arichtman]

Someone pointed me at this - sharing in case it helps someone
https://github.com/hraban/mac-app-util

[AntonyBlakey]

I have found that the following is required for me. A couple of changes from the most recent above:

• run the script after "linkGeneration", otherwise home manager hasn't created it's own links, and you will be using the previous generation I think.
• Modify the find because home manager creates nested symlinks, and you want to pick up .app directories as the targets.
• On my machine at least, home manager uses home-files not home-path

# Need to create aliases because Launchbar doesn't look through symlinks.
home.activation.link-apps = lib.hm.dag.entryAfter [ "linkGeneration" ] ''
  new_nix_apps="${config.home.homeDirectory}/Applications/Nix"
  rm -rf "$new_nix_apps"
  mkdir -p "$new_nix_apps"
  find -H -L "$genProfilePath/home-files/Applications" -name "*.app" -type d -print | while read -r app; do
    real_app=$(readlink -f "$app")
    app_name=$(basename "$app")
    target_app="$new_nix_apps/$app_name"
    echo "Alias '$real_app' to '$target_app'"
    ${pkgs.mkalias}/bin/mkalias "$real_app" "$target_app"
  done
'';

[AntonyBlakey]

run the script after "linkGeneration", otherwise home manager hasn't created it's own links, and you will be using the previous generation I think.

I have just discovered that you should replace $genProfilePath with $newGenPath in the find, and then you can leave the sequencing to be after "writeBarrier". This is more correct.

[nvmd]

I've tried @AntonyBlakey's solution. Using find to find “real” targets seems like a nice idea.

The minor issue I had is that it may also pick up and link *.apps that are not intended for an end-user. For example, with UTM it makes an alias for an internal QEMULauncher.app:

Alias '/nix/store/hsvx9x41c15py99bqnmdg29gkkrlb0fm-utm-4.5.3/Applications/UTM.app' to '/Users/<user>/Applications/Nix/UTM.app'
Alias '/nix/store/hsvx9x41c15py99bqnmdg29gkkrlb0fm-utm-4.5.3/Applications/UTM.app/Contents/XPCServices/QEMUHelper.xpc/Contents/MacOS/QEMULauncher.app' to '/Users/<user>/Applications/Nix/QEMULauncher.app'

Specifying the -maxdepth 1 argument for find (before -name) fixes that. However, I'm unsure if 1 is the universally correct value, though. Or if can it be reliably predetermined like that for all cases.

[Kristina-Pianykh]

The solution in https://github.com/hraban/mac-app-util worked like a charm for me. Just include it as a flake input and activate the home-manage.

[jackmac92]

@Kristina-Pianykh you're talking about mktrampoline right? https://github.com/hraban/mac-app-util?tab=readme-ov-file#mktrampoline

[Kristina-Pianykh]

@Kristina-Pianykh you're talking about mktrampoline right? https://github.com/hraban/mac-app-util?tab=readme-ov-file#mktrampoline

You can either include mac-app-util as a Flake input in your Nix/home-manager config if you use it or just run the command https://github.com/hraban/mac-app-util?tab=readme-ov-file#mktrampoline manually

[pshirshov]

There is a problem with trampoline approach: hraban/mac-app-util#19

I'm not sure if it can be solved at all, but it's still worth to document.