Change artifact behavior to moving instead of symlinking

[mwean]

This is a first step towards change in installation behavior mentioned in #13201.
I had to skip the two_apps_correct tests because I don't know the desired functionality (e.g. should we copy the source to both targets and delete the source?)

[RomainLanz]

Any news on this?

[mwean]

I'm waiting for feedback from @jawshooah to make sure this is the correct approach.

[jawshooah]

This method can be removed, as it's not used anywhere.

[vitorgalvao]

@mwean Just to check, do you still intend on working on this?

[mwean]

@vitorgalvao Yeah I'd definitely like to. I just moved, but I'll try to take a look this weekend.

[mwean]

@vitorgalvao I rebased against master and made a couple more updates. I'm not sure what else needs to be done, and I don't know what the correct behavior should be for the two-app tests. I could maybe copy to both locations and delete the original? I'm not sure what the use case for that is. Let me know what you think.

[adidalal]

I agree that the two-app tests seem useless; at least, I've never seen it.
@jawshooah if you want to take a look at the PR when you're free?

[jawshooah]

Will take another look at this tonight.

[ptb]

I found one issue with this pull request, but unsure how to correctly correct it. If an app, Atom for example, has a binary that needs to be symlinked to /usr/local/bin, it complains that the symlink source isn't there. The workaround I've used is:

sed -i -e "s/@cask.staged_path/Hbc.appdir/" /usr/local/Library/Taps/caskroom/homebrew-cask/lib/hbc/artifact/symlinked.rb

but that breaks installs for fonts (at least). I'm not sure what the correct solution is, but figured I'd add that bit.

[mwean]

@ptb are you saying that it tries to symlink the binary before it moves the app?

[ptb]

No it tries to symlink after moving, but it expects that it still lives at the staged location (Caskroom).

brew cask install atom --force
==> Satisfying dependencies
complete
==> Downloading https://github.com/atom/atom/releases/download/v1.4.3/atom-mac.zip
######################################################################## 100.0%
==> Verifying checksum for Cask atom
==> Moving App 'Atom.app' to '/Users/admin/Applications/Atom.app'
Error: It seems the symlink source is not there: '/opt/homebrew-cask/Caskroom/atom/1.4.3/Atom.app/Contents/Resources/app/apm/node_modules/.bin/apm'

[vitorgalvao]

It had occurred to me recently this might be an issue. Basically this only happens if the binary to be linked is inside the app.

The solution would be to instead of having (to borrow atom as the example)

binary 'Atom.app/Contents/Resources/app/apm/node_modules/.bin/apm', target: 'apm'

have

binary "#{Hbc.appdir}/#{app[0]}/Contents/Resources/app/apm/node_modules/.bin/apm", target: 'apm'

Though that particular solution doesn’t work. All that’s needed is to add a new app_location (or something) special variable that we can employ in these cases, to just grab the install location.

[mwean]

@ptb @vitorgalvao I made a failing spec for the embedded binary case, but I'm not sure how to proceed. I'm a little concerned putting interpolations into the path declaration like @vitorgalvao suggested because it would require Cask authors to know more about the cask inner workings. I wonder if we could match the beginning of the binary path against the app path (the "Atom.app" part in this example):

app 'Atom.app'
binary 'Atom.app/Contents/Resources/app/atom.sh', target: 'atom'

If there's a match, we'd know to look in the appdir. It would be a little ugly because we'd have to look at the app's artifacts from the symlink class, but it wouldn't require any change to the dsl. What do you think?

[vitorgalvao]

I feel like you’re trying to make the feature smart, and smart is what got us in this mess in the first place are we’re trying to avoid.

It is not a huge user-facing change. I’d much rather have it be explicit and work, even if it means contributors need to know something new, than having something smart that later on we find breaks on some cases.

It’s better to have it be dumb and make it smarter later, than the reverse.

[toonetown]

@mwean
it would require Cask authors to know more about the cask inner workings

I tend to agree with @vitorgalvao in that cask authors should be expected to know more about the cask inner workings. It should be simple and dumb and easy for end users to use and not get into trouble...but (IMO), it's OK to expect cask authors to need to know what they are doing.

It should be generally easy to create a cask...but it doesn't hurt to know the inner workings a bit in order to create one.

[mwean]

Ok, that sounds good. What about having tokens instead of direct interpolation (like they do in Paperclip)? Something like

binary ":install_location/:app/Contents/Resources/app/apm/node_modules/.bin/apm"

[muescha]

code snippet for brew cask install google-chrome should be changed from Symlinking to Moving (line 23 of collapsed code in diff)

[vitorgalvao]

This one I have already fixed yesterday.

[mwean]

@muescha I think there was a bad rebase that reverted my doc changes. I'll make a new PR to fix them

[vitorgalvao]

Fixing issues caught by @muescha in #21597.

[toonetown]

I just have to say, it might be completely in my head (or due to the fact that I uninstalled/reinstalled all my casks to get the "move" behavior), but my applications seem to launch a LOT faster and spotlight seems to be a LOT more responsive since this change has been implemented. Nice work!!!