I'm writing a homebrew formula for a project (https://www.cryfs.org).
Since it is a file system, it depends on osxfuse, which is unfortunately only available as a cask. That is, the formula should have the cask as a dependency.
I tried the following
depends_on :cask => "osxfuse"
but I got the error message
Unsupported special dependency :cask
What is the syntax for adding casks as dependencies to a formula?
Couldn't find an answer to this problem either.
But as a poor mans workaround this serves well for the time being:
def install
# Resolve cask dependencies
system "/usr/local/bin/brew", "cask", "install", "osxfuse"
The big disadvantage is obvious, its not a so much of dependency relation than an installation command. Which may lead to problems until you actually install the package.
Based on other formulas it seems like it needs to be depends_on cask: instead of :cask. There are multiple places where modules depend on a specific cask/macosx version and are defined as such: depends_on macos: "". Example of an cask dependency inside a cask formula.
depends_on cask: => "osxfuse"
Give me an heads up if it worked!
Have you tried:
depends_on "caskroom/cask/osxfuse"
Related
I am trying to install maven 3.6.3 by brew command but not working as latest is maven 3.8.2
brew install maven
Any idea??
Most Homebrew formulae are named in such a way that the version is part of the formula's name. For example, maven#3.5.
Check out the specs for the maven formula: https://formulae.brew.sh/api/formula/maven.json. You'll find that maven has the alias maven#3.8. Usually, formulae without version numbers have an alias with the version number. However, maven#3.8 is not its own package.
However, there are some versioned formulae. For example, maven#3.5, found here.
Long-story short, if you look at versioned_formulae in the maven formula, you'll find that there is no formulae for Maven 3.6. Not sure why because I am positive that it used to be.
You could try writing your own formula or downloading the specific version from the website: https://archive.apache.org/dist/maven/maven-3/3.6.3/binaries/.
I’m writing a brew formula for my own tap, having XQuartz and external sources (not available on brew) as dependencies. How can I include them in my formula?
See the answer on the brew discourse: https://discourse.brew.sh/t/brew-formula-how-can-i-define-external-dependencies/2358/3.
You need to install those sources by using an existing tap or creating a new one.
this is my first question on StackOverflow. Usually I find a solution from someone else's question but this time the internet does not seem to have many answers.
So I'm getting this message after using go get and every time I try and compile and run my application.
# pkg-config --cflags rdkafka
Package rdkafka was not found in the pkg-config
search path. Perhaps you should add the directory containing `rdkafka.pc'
to the PKG_CONFIG_PATH environment variable Package 'rdkafka', required by
'virtual:world', not found
I searched the issues on the github page for the repo and found one thread related to this, but none of those solutions seem to work for me. I'm running fedora 26, I have go 1.9 installed.
I've tried:
dnf install
Compiling from source as instructed on their README
yum install because I became desperate.
Downloading and installing from the RPM
Has anyone come accross this and maybe have an idea of how I can fix it?
I suggest that you install librdkafka from Confluent's repository as described in their documentation. But I think that you'll need to build librdkafka from source RPMs, like I'm doing for Ubuntu.
So I got it working thanks to Remi. Adding the repo from https://rpms.remirepo.net/ (I used the one for Fedora 26). Then just installing it using:
sudo dnf --enablerepo=remi install librdkafka-devel
We're developing runscripts and try to support something like brew install runscripts.
It's written in golang and have some dependencies which required to go get. Now I have no idea to write the Formula to setup GOPATH and run go get. Our project can be compiled into an binary but we need run --init to install it.
Can anyone helps to give an example about a homebrew Formula of go project?
Fork homebrew, look at the content of Library/Formula/consul.rb. You don't need to manually generate all the resources. Use homebrew-go-resources. A more complete intro could be found here.
I have refer to termshare.rb and it seems we can simply go get and homebrew will handle anything about GOPATH for us.
That's great and I think my problem is solved.
The best I could find is how docker-swarm is added to brew: https://github.com/Homebrew/homebrew/blob/4c6857b0e337b2d5afd49dcf7209b6b5091709f4/Library/Formula/docker-swarm.rb
It's relatively clean and simple to follow.
You can use goreleaser to generate the formula automatically: https://goreleaser.com/customization/homebrew/
Here is a possible work around creating a build directory within the checkout as the GOPATH:
...
def install
system "mkdir -p build/src"
system "ln -s `pwd` build/src/repo"
system "GOPATH=`pwd`/build go get repo/mytool"
bin.install "build/bin/mytool"
...
end
...
Today I installed the curl formula via homebrew, but after installing it (and re-sourcing the shell) i noticed that :
% which curl
/usr/bin/curl
as a matter of fact, the output of brew install curl stated that it was a keg-only formula, and that since curl was already present in OS X, it didn't link it into Homebrew prefix, as that could cause unspecified problems.
Then it proceeds stating that
Generally there are no consequences of this for you
I would like to know:
What sorts of problems exactly?
What is the purpose of installing keg-only formulas via Homebrew? How can there be no consequences if the newly installed tool is not in the PATH?
Problems: if a homebrew application is put in the path in front of the default OS X version of the same, really anything might happen. Most common issues are caused by differences between the set of command line options available in the two versions, or differences in the meaning of the options. For curl the consequences might not be so bad, but for other applications you could, at worst, break the OS.
Keg-only: now you have two versions of curl! The default OS X, and the homebrew. If you want to use features that are not in the default but in the homebrew, you can do so by calling the homebrew curl explicitly. The precise path depends on how you've got homebrew set up. Because the newly installed version is not in the path, its unlikely to cause a problem unless it is explicitly called.
I want to add some complement to the second problem(related to the mechanism of keg-only) asked by #asymmetric.
HomeBrew's prefix is /usr/local , and HomeBrew keeps all installed kegs in the default directory, say /usr/local/Cellar. In general, HomeBrew could create symlink for installed formula(non-keg-only formula), and the corresponding symlink is kept in /usr/local/bin. This symlink-creation procedure is automatic when HomeBrew installing the formula. Here the path /usr/local/bin would be called default (symlink) prefix.
On the other hand, according to FAQ of HomeBrew, we have the following guidance:
``keg-only formula is installed only into the Cellar and is not linked into the default prefix. This means most tools will not find it.''
But at the same time the HomeBrew creates symlinks in the directory /usr/local/opt for ALL installed formulae no matter whether they are keg-only or not.
There will be two crucial points we should notice:
By default the default (symlink) prefix /usr/local/bin is in PATH, but the non-prefix /usr/local/opt is NOT in PATH.
By default the default (symlink) prefix /usr/local/bin in general points towards the latest version of formula. So if you want to use the specific version(often in keg-only format) of some formula you could temporarily prepend your PATH with the keg-only formula's bin directory, for example, export PATH="$(brew --prefix)/opt/FormulaName/bin:${PATH}".
The setting of /usr/local/opt mentioned above could resolve the executable-conflict. In general, you might have a formula or program in your system with many different versions, such as the latest version and outdated version, the Apple native version and locally installed version, an so on. It's possible for these situations to cause conflict when you execute or compile some other programs which are somewhat related to the current using formula or program.