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

Change artifact behavior to moving instead of symlinking #13966

Merged
merged 9 commits into from May 31, 2016

Conversation

Projects
None yet
@mwean
Contributor

mwean commented Sep 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@RomainLanz

RomainLanz Nov 25, 2015

Any news on this?

RomainLanz commented Nov 25, 2015

Any news on this?

@mwean

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean Nov 25, 2015

Contributor

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

Contributor

mwean commented Nov 25, 2015

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

@vitorgalvao

This comment has been minimized.

Show comment
Hide comment
@vitorgalvao

vitorgalvao Jan 3, 2016

Member

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

Member

vitorgalvao commented Jan 3, 2016

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

@mwean

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean Jan 4, 2016

Contributor

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

Contributor

mwean commented Jan 4, 2016

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

@mwean

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean Feb 1, 2016

Contributor

@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.

Contributor

mwean commented Feb 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@adidalal

adidalal Feb 1, 2016

Member

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?

Member

adidalal commented Feb 1, 2016

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?

@adidalal adidalal changed the title from DON'T MERGE - Change app artifact to move instead of link to [WIP] Change artifact behavior to moving instead of symlinking Feb 1, 2016

@jawshooah

This comment has been minimized.

Show comment
Hide comment
@jawshooah

jawshooah Feb 2, 2016

Contributor

Will take another look at this tonight.

Contributor

jawshooah commented Feb 2, 2016

Will take another look at this tonight.

@ptb

This comment has been minimized.

Show comment
Hide comment
@ptb

ptb Feb 9, 2016

Contributor

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.

Contributor

ptb commented Feb 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean Feb 9, 2016

Contributor

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

Contributor

mwean commented Feb 9, 2016

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

@ptb

This comment has been minimized.

Show comment
Hide comment
@ptb

ptb Feb 9, 2016

Contributor

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'
Contributor

ptb commented Feb 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vitorgalvao

vitorgalvao Feb 9, 2016

Member

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.

Member

vitorgalvao commented Feb 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean May 17, 2016

Contributor

@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?

Contributor

mwean commented May 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@vitorgalvao

vitorgalvao May 17, 2016

Member

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.

Member

vitorgalvao commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@toonetown

toonetown May 17, 2016

Contributor

@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.

Contributor

toonetown commented May 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean May 17, 2016

Contributor

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"
Contributor

mwean commented May 17, 2016

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"
@vitorgalvao

This comment has been minimized.

Show comment
Hide comment
@vitorgalvao

vitorgalvao May 17, 2016

Member

Tokens seem clunky, to me. We use interpolation for some things, and symbols for others. They are well defined and predictable. Mixing here seems inappropriate.

Also, we really need a way to specify the index of what we mean. Some apps have multiple app stanzas, so we need to specify the one we’re pointing to. Something like binary "#{app_install_location}/#{app[0]}/…" seems acceptable, to me. We need to specify it’s the install location reserved for apps, in case we later need to do it for other artifacts.

Member

vitorgalvao commented May 17, 2016

Tokens seem clunky, to me. We use interpolation for some things, and symbols for others. They are well defined and predictable. Mixing here seems inappropriate.

Also, we really need a way to specify the index of what we mean. Some apps have multiple app stanzas, so we need to specify the one we’re pointing to. Something like binary "#{app_install_location}/#{app[0]}/…" seems acceptable, to me. We need to specify it’s the install location reserved for apps, in case we later need to do it for other artifacts.

@mwean

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean May 17, 2016

Contributor

Ok, I actually wasn't clear what app[0] was referring to in your earlier comment. Could we do something more explicit like app_specifications[0].name? Something shorter would be better but I can't think of anything right now.

Contributor

mwean commented May 17, 2016

Ok, I actually wasn't clear what app[0] was referring to in your earlier comment. Could we do something more explicit like app_specifications[0].name? Something shorter would be better but I can't think of anything right now.

@@ -30,7 +30,7 @@ $ brew cask install google-chrome
And there we have it. Google Chrome installed with a few quick commands: no clicking, no dragging, no dropping.

This comment has been minimized.

@muescha

muescha Jun 1, 2016

Contributor

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

@muescha

muescha Jun 1, 2016

Contributor

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

This comment has been minimized.

@vitorgalvao

vitorgalvao Jun 1, 2016

Member

This one I have already fixed yesterday.

@vitorgalvao

vitorgalvao Jun 1, 2016

Member

This one I have already fixed yesterday.

@@ -53,7 +53,7 @@ Easy peasy:
$ brew cask uninstall google-chrome
```

This comment has been minimized.

@muescha

muescha Jun 1, 2016

Contributor

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

@muescha

muescha Jun 1, 2016

Contributor

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

This comment has been minimized.

@vitorgalvao

vitorgalvao Jun 1, 2016

Member

This one I have already fixed yesterday as well.

@vitorgalvao

vitorgalvao Jun 1, 2016

Member

This one I have already fixed yesterday as well.

@mwean

This comment has been minimized.

Show comment
Hide comment
@mwean

mwean Jun 1, 2016

Contributor

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

Contributor

mwean commented Jun 1, 2016

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

arbourd added a commit to arbourd/dotfiles that referenced this pull request Jun 1, 2016

@vitorgalvao

This comment has been minimized.

Show comment
Hide comment
@vitorgalvao

vitorgalvao Jun 1, 2016

Member

Fixing issues caught by @muescha in #21597.

Member

vitorgalvao commented Jun 1, 2016

Fixing issues caught by @muescha in #21597.

@toonetown

This comment has been minimized.

Show comment
Hide comment
@toonetown

toonetown Jun 1, 2016

Contributor

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!!!

Contributor

toonetown commented Jun 1, 2016

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!!!

@vitorgalvao vitorgalvao referenced this pull request Jun 11, 2016

Merged

Change default Caskroom path #21857

1 of 1 task complete

chiselwright added a commit to chiselwright/homebrew-cask that referenced this pull request Jun 15, 2016

sage.rb: Switch mirror; update to v7.2; fix URLs (#21353)
The latest stable version of SageMath is [7.2](http://mirrors.mit.edu/sage/osx/intel/index.html) and can be found on the MIT mirror.

Currently, the El Capitan branch of this cask is broken because it points to [go-parts.com](http://mirrors-usa.go-parts.com/sage/sagemath/osx/intel/), a mirror which seems not to carry neither the stable 7.1 version nor the current stable v7.2.

The site is also not part of the [list of download servers on sagemath.org](http://www.sagemath.org/download-mac.html). Because of this, I switched the El Capitan branch to point to mirrors.mit.edu/sage just like the other branches do.

This commit also updates broken URLs for the Mavericks and Yosemite branches.

http://mirrors.mit.edu/sage/osx/intel/sage-7.2-OSX_10.11.4-x86_64.tar.bz2

This cask also happens to symlink a binary which lives inside the moved artifact. So this is one of the cases where we might want to use the new `appdir` method that is being introduced in #13966.

chiselwright added a commit to chiselwright/homebrew-cask that referenced this pull request Jun 15, 2016

Fix triumph.rb: Remove DDP Player.app artifact (#21413)
Triumph.app contains in its bundle three helper tools. Those tools are meant to be accessed from the menu bar while using Triumph.

One of those tools, DDP Player.app, is defined as an artifact though. With upcoming PR #13966, `cask install` would rip out DDP Player.app from the bundle. As a consequence, invoking the *DDP Player* menu item would cause Triumph to crash.

This commit fixes the issue by removing the artifact altogether. All the tools (including DDP Player) should be launched from the *Tools* menu as intended, e. g.:

> Triumph » Tools » DDP Player

chiselwright added a commit to chiselwright/homebrew-cask that referenced this pull request Jun 15, 2016

[WIP] Change artifact behavior to moving instead of symlinking (#13966)
* Change app artifact to move instead of link

First step towards change in installation behavior mentioned in [13201]

* Fix handling of binaries linked from inside of app bundles

Also adds `appdir` method for interpolation in stanzas

* Change appdir to root Applications directory

* Update 2-app tests

* Refactor: add options, ivars to `Installer`, `Download`

In preparation for upcoming changes, this commit cleans up some code. The commit includes:

- In order to reduce unnecessary object passing, make both the `force` and `skip_cask_deps` option into instance variables of the `Installer` class

- Introduce options hashes to initializers of both the `Installer` and `Download` class

- When the `install --force` command enters the fetch phase, make it explicit in the code that fetching is never enforced in that case.

- Update tests

* Force overwrite artifacts on `--force` reinstall

This commit changes the behavior of a `Moved` artifact such that if the target already exists, `brew cask install --force` will remove the existing target before moving the staged artifact.

In that case, the warning message will say *overwriting* instead of *not moving*.

The behavior of plain `brew cask install` remains unchanged; the same goes for the warning message for that case.

* Change remaining artifacts to move instead of symlink

* Update casks to use appdir in binary paths

* Forcibly overwrite artifacts, modifying flags and using `sudo` if needed

- This commit implements [the proposed behavior for `install --force`](Homebrew#13966 (comment)) when a target already exists and has either permission problems or is not owned by the user.

- The changes apply only when the `force` option is given.

- Reused the existing safeguard from the `.pkg` artifact to prevent deleting important directories by bug or mistake

- The two existing blacklists `SYSTEM_DIRS` and `UNDELETABLE_DIRS` have been consolidated into the `Hbc::MacOS` module.

- `UNDELETABLE_DIRS` now also contains all the entries from `SYSTEM_DIRS` which was a to-do anyway.

- The two blacklists are now also frozen for good measure.

- The utility method `permissions_rmtree` was moved to `Hbc::Utils`.

- The `tried_permissions` part in `Utils` now falls back correctly when there are also ownership issues at the same time.

- Introduced a separate `current_user` method for mocking.

- Added an optional feature to `FakeSystemCommand` so it can now act as a proxy to `SystemCommand`.

- Added tests for various `permissions_rmtree` cases.

@joewiz joewiz referenced this pull request Jul 2, 2016

Merged

Tell users to delete old caskroom if it exists #22387

1 of 1 task complete

@leee leee referenced this pull request Oct 7, 2016

Merged

Redocument the `artifact` stanza per #13966 #25290

0 of 8 tasks complete

@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.