https://github.com/Homebrew/homebrew-cask
It doesn't explain why cask is needed, why not just use homebrew. Could anybody explain why it is needed? Why not just put all the cask packages into the bare homebrew? Thanks.
Cask started as a separate project according to this answer and is primarily for graphical apps and packages that might not meet the license guidelines for regular brew packages. This comment on a Github issue explains that the reason they're kept separate is that cask provides packages that are already compiled, and why that's important, namely, that the behavior of brew and brew cask are different, so should be separate.
Related
I'm new to brew. Why does brew have both a python and a python#3.8 package? If I do a "brew search", many of the packages don't have version numbers in them.
It's also interesting how if I do a "brew search openssl", it only shows me openss#1.1, but not just openssl.
What Mark said is right, we have big chunk of homebrew formulae depends on Python. So using versioned formula would be easier for us to prioritize the python 3.8 migration (we do even have a migration label for it.)
As you know this is the first year for fully deprecate Python 2, which would be painful for any package manager to do the inventory check. :)
I'm using Home Brew on my system to allow users to install some packages; there are some that are installed at the system level (e.g. build-essential) but when I run a formula brew is not able to see them and download them. Is this the expected behavior or is there something I can do to fix this?
It's an expected behavior. Homebrew on Linux, namely Linuxbrew, uses its own libraries.
Homebrew does not use any libraries provided by your host system, except glibc and gcc if they are new enough. Homebrew can install its own current versions of glibc and gcc for older distributions of Linux.
References
Homebrew documentation of Linuxbrew
I'm familiarizing myself with the whole homebrew kit and the documentation is rather poor.
What is a cask, Cellar and a tap?
Homebrew-Cask is an extension to Homebrew to install GUI applications such as Google Chrome or Atom. It started independently but its maintainers now work closely with Homebrew’s core team.
Homebrew calls its package definition files “formulae” (British plural for “formula”). Homebrew-Cask calls them “casks”. A cask, just like a formula, is a file written in a Ruby-based DSL that describes how to install something.
The Cellar is where Homebrew installs things. Its default path is /usr/local/Cellar (/opt/homebrew/Cellar on Apple Silicon). It then add symlinks from standard locations to it.
For example, when you type brew install git:
Homebrew installs it under /usr/local/Cellar/git/<version>/, with the git binary in /usr/local/Cellar/git/<version>/bin/git
It adds a symlink from /usr/local/bin/git to that binary
This allows Homebrew to keep track of what’s installed by Homebrew versus software installed by other means.
A tap is a source of formulae. The default is homebrew/core but you can add more of them. The simplest way to create a formula for your own software is to create a GitHub repository called homebrew-<something>; put your formula file in it; then type brew tap <username>/<something> to add this new source of formulae to your Homebrew installation and so get access to all its formulae.
Some companies have internal Homebrew taps for their own utilities. There are a lot of public taps like atlassian/tap for Atlassian software, or ska-sa/tap for radio astronomy. Homebrew itself used to have additional taps like homebrew/science but they deprecated them and imported the formulæ in homebrew/core.
I personally differentiate brew & cask just based on 1 of the main (if not the only main) differences, of graphical GUI applications being managed by cask rather than just brew. (There are other differences too which I don't know as much about).
Below adapted from 'Graham Miln' on apple.stackexchange:
Homebrew
brew is the core command for the Homebrew project.
The missing package manager for OS X
Homebrew installs the stuff you need that Apple didn’t.
Homebrew typically deals with command line software (not graphical GUI applications). Most of the software is distributed under an open source licence.
Cask
brew cask is an extension to brew that allows management of graphical GUI applications.
Homebrew Cask extends Homebrew and brings its elegance, simplicity,
and speed to OS X applications and large binaries alike.
Cask deals with a mixture of software and licences.
Cask offers a way to command line manage the installation of graphical GUI applications.
Licensing
Availability through brew or cask does not imply any specific licence.
Quoting from official docs:
Cask
https://github.com/Homebrew/homebrew-cask
Homebrew Cask extends Homebrew and brings its elegance, simplicity,
and speed to the installation and management of GUI macOS applications
such as Atom and Google Chrome.
Cellar
https://docs.brew.sh/Formula-Cookbook
Homebrew installs to the Cellar and then symlinks some of the
installation into /usr/local so that other programs can see what’s
going on.
Tap
https://docs.brew.sh/Taps
Taps (Third-Party Repositories)
brew tap adds more repositories to the
list of formulae that brew tracks, updates, and installs from. By
default, tap assumes that the repositories come from GitHub, but the
command isn’t limited to any one location.
Update on command:
The current version of homebrew deprecated the "brew cask" syntax. From now on, se the --cask modifier instead.
brew --cask
I want to switch to Homebrew instead of MacPorts because Homebrew told me to (http://cl.ly/image/1b0M0q2x1C3K) and it seems better.
I'm a bit weary about how to uninstall MacPorts since it's installed trough Terminal and not trough .app as a regular OS X program.
How do I uninstall?
sudo port -f uninstall installed
will uninstall all ports.
Then read the guide for cleaning up the leftover bits.
https://guide.macports.org/chunked/installing.macports.uninstalling.html
You can use brew along with macports without any issues as brew installs the packages under a different directory.
I have been using both of these package managers without any problems.
Macports and Brew are better in their own way, you never know when you might want to use macports, it is going to get better and faster.
I tend to use both depending on what I want to install and do further.
If you still insist on uninstalling MacPorts, you can follow the steps as mentioned by Kirk Roybal.
I know this is an old post.
But for clarity: brew installs to /usr/local. macports installs to /opt/local. When you have duplicates (binaries, objects, libraries) and/or version difference (i.e. duplicates that have the same name but are different versions), then you can have issues if you do not manage it. Manage it through your command search rules (PATH in bash,csh for example) and your library search rules if applicable. If you have a collision that can't be resolved this way or you don't want to deal with it, then you have to pick one - i.e. delete the one you don't want and replace it with a link to the one to keep. I've used both MacPorts and Brew for a long time successfully.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I've just recently switched to a Mac from Ubuntu. I was disappointed that mac doesn't have the convenient sudo apt-get in Ubuntu. I've heard that I should use homebrew but I'm not exactly sure what homebrew or macports does?
MacPorts is the way to go.
Like #user475443 pointed, MacPorts has many many more packages. With brew you'll find yourself trapped soon because the formula you need doesn't exist.
MacPorts is a native application: C + TCL. You don't need Ruby at all. To install Ruby on Mac OS X you might need MacPorts, so just go with MacPorts and you'll be happy.
MacPorts is really stable, in 8 years I never had a problem with it, and my entire Unix ecosystem relay on it.
If you are a PHP developer you can install the last version of Apache (Mac OS X uses 2.2), PHP and all the extensions you need, then upgrade all with one command. Forget to do the same with Homebrew.
MacPorts support groups.
foo#macpro:~/ port select --summary
Name Selected Options
==== ======== =======
db none db46 none
gcc none gcc42 llvm-gcc42 mp-gcc48 none
llvm none mp-llvm-3.3 none
mysql mysql56 mysql56 none
php php55 php55 php56 none
postgresql postgresql94 postgresql93 postgresql94 none
python none python24 python25-apple python26-apple python27 python27-apple none
If you have both PHP55 and PHP56 installed (with many different extensions), you can swap between them with just one command. All the relative extensions are part of the group and they will be activated within the chosen group: php55 or php56. I'm not sure Homebrew has this feature.
Rubists like to rewrite everything in Ruby, because the only thing they are at ease is Ruby itself.
Homebrew and macports both solve the same problem - that is the installation of common libraries and utilities that are not bundled with osx.
Typically these are development related libraries and the most common use of these tools is for developers working on osx.
They both need the xcode command line tools installed (which you can download separately from https://developer.apple.com/), and for some specific packages you will need the entire xcode IDE installed.
xcode can be installed from the mac app store, its a free download but it takes a while since its around 5GB (if I remember correctly).
macports is an osx version of the port utility from BSD (as osx is derived from BSD, this was a natural choice). For anyone familiar with any of the BSD distributions, macports will feel right at home.
One major difference between homebrew and macports; and the reason I prefer homebrew is that it will not overwrite things that should be installed "natively" in osx. This means that if there is a native package available, homebrew will notify you instead of overwriting it and causing problems further down the line. It also installs libraries in the user space (thus, you don't need to use "sudo" to install things). This helps when getting rid of libraries as well since everything is in a path accessible to you.
homebrew also enjoys a more active user community and its packages (called formulas) are updated quite often.
macports does not overwrite native OSX packages - it supplies its own
version - This is the main reason I prefer macports over home-brew, you
need to be certain of what you are using and Apple's change at
different times to the ports and have been know to be years behind
updates in some projects
Can you give a reference showing that macports overwrites native OS X
packages? As far as I can tell, all macports installation happens in
/opt/local
Perhaps I should clarify - I did not say anywhere in my answer that macports overwrites OSX native packages. They both install items separately.
Homebrew will warn you when you should install things "natively" (using the library/tool's preferred installer) for better compatibility. This is what I meant. It will also use as many of the local libraries that are available in OS X. From the wiki:
We really don’t like dupes in Homebrew/homebrew
However, we do like dupes in the tap!
Stuff that comes with OS X or is a library that is provided by
RubyGems, CPAN or PyPi should not be duped. There are good reasons for
this:
Duplicate libraries regularly break builds
Subtle bugs emerge with duplicate libraries, and to a lesser extent, duplicate tools
We want you to try harder to make your formula work with what OS X comes with
You can optionally overwrite the macosx supplied versions of utilities with homebrew.
Currently, Macports has many more packages (~18.6 K) than there are Homebrew formulae (~3.1K), owing to its maturity. Homebrew is slowly catching up though.
Macport packages tend to be maintained by a single person.
Macports can keep multiple versions of packages around, and you can enable or disable them to test things out. Sometimes this list can get corrupted and you have to manually edit it to get things back in order, although this is not too hard.
Both package managers will ask to be regularly updated. This can take some time.
Note: you can have both package managers on your system! It is not one or the other. Brew might complain but Macports won't.
Also, if you are dealing with python or ruby packages, use a virtual environment wherever possible.
By default, Homebrew installs packages to your /usr/local. Macport commands require sudo to install and upgrade (similar to apt-get in Ubuntu).
For more detail:
This site suggests using Hombrew: http://deephill.com/macports-vs-homebrew/
whereas this site lists the advantages of using Macports: http://arstechnica.com/civis/viewtopic.php?f=19&t=1207907
I also switched from Ubuntu recently, and I enjoy using homebrew (it's simple and easy to use!), but if you feel attached to using sudo, Macports might be the better way to go!