-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
Implement depends_on :cask
#8491
Implement depends_on :cask
#8491
Conversation
In the interest of `depends_on :cask`, we introduce a topologically sortable hashmap, implemented as a small subclass of Hash.
as a class concerned with recursively loading, graphing and sorting all dependencies of a given Cask.
Includes an unsavory hack to bypass redundant checks for Cask subdependencies, in the form of an optional argument passed down from `install` to `satisfy_dependencies`.
Warts or not, it is a much-wanted feature, and looks mergeable. My only question after reading is why everything happens in the constructor. (Not that it matters in practice, because you read the dependencies in the next line after instantiation.) |
No reason other than overlap and utility. A naked array of first-level dependencies is already available at the DSL level as If desired, I have no qualm with refactoring the class into a more conventional structure. |
Just curious, no need to bother with refactoring. The name is also perfectly descriptive, if you think of a deps.sorted.each do |dep_token| could be spelled without the deps.each do |dep_token| |
Implement `depends_on :cask`
This PR includes library and (some) test code for hard Cask dependencies, i.e. Casks which must always be installed prior to the depender.
There are some warts. Most notably:
skip_cask_deps
, is passed down fromCask::Installer.install
tosatisfy_dependencies
, in order to avoid redundant loading and (re)sorting of Cask subdependencies.Secondarily:
extend
, but it is reserved for monkeypatches.