It is based on Debian Linux apt-get and has a nice GUI tool for seeing and maintaining packages. I use MacPorts and I’ve used Fink in the past. This is useful if you need to customize your (L)AMP stack, or process a document in LaTeX, or do graphing visualization or -code optimization… there are a lot of uses and having a consistent Linux-like or BSD-like tree of libraries and applications is usually the best option. What they are, are ways of installing Unix (Linux or BSD) software on your Macintosh in a way that they get updated. A good way to start doing that is to install some things manually, using make, and taking the time to learn the conventions about what goes where, how the path works, and where compilers and build utilities look for things.īut, sure, if that sounds terrible, just use Homebrew.A friend asks whether they should use MacPorts or Homebrew. I do recommend Homebrew, but I think it's also important, if you want to avoid a lot of hair-tearing throughout your computing future, to understand the way Unix software works and how different pieces work together. (Partly that is also a consequence of the ease of writing install scripts, in Ruby.) It also makes it easy to find help if you do run into trouble. It turns out, perhaps unsurprisingly, that life is a little more pleasant when you use a Unix system in a way that accords closely with Unix conventions, rather than trying to segregate different sets of software in rigid and unusual ways.īut the biggest reason I'm happy with Homebrew is simply that it seems to have the largest and more active community of users, which means that the software (and version) you're lookin for is likelier to be available on Homebrew than it is on MacPorts or Fink. In my experience, I have run into far fewer frustrating path issues using Homebrew than I used to with MacPorts. This also makes it easy to put Unix executables like mvim, the binary for MacVim that can be invoked from the command line, on the system path, etc., without having to dive into app bundles. This is much easier and fool-proof than trying to do something similar on your own, particularly with software (like LaTeX) that has lots of separate pieces.Īll of this works very well for things within the managed ecosystem, but it also makes it much easier (in comparison with other package managers) to use Homebrew-managed software with other Unix software that you've installed in another way, since the active Homebrew package will always be on your path in the conventional location that other pieces of software expect it to be. That includes a higher-level tool for switching between different versions of the same piece of software, which works by unlinking the currently active versions and linking a different version instead. Homebrew provides convenient facilities for checking what's linked where, and for linking and unlinking the contents of packages to conventional locations on your path (as well as for uninstalling them completely). Everything gets installed into a package- and version-specific directory in your Cellar directory (which is /usr/local/Cellar by default, but it can be anywhere) and then it selectively symlinks executables into /usr/local/bin and other conventional locations as appropriate. While it's true that Homebrew uses contentional Unix installation directories, it does not install things willy-nilly into /usr/local/bin or /usr/local/lib. My notes on working with MacPorts are here. I am willing to bet that there are cases where Homebrew or Fink are better than MacPorts. Fortunately, a wiser person than me pointed me (back) to MacPorts.Īll that noted, like many things, it all depends on what software / functionality you are trying to manage with one of the three. I generally prefer Homebrew, but I have found that in my particular case, working with Python, MacPorts excels at making everything "just work." I fought and fought to get SciPy and Numpy and the NLTK up and running on my Mac using Homebrew, but it just wasn't happening. One of the greatest strengths of such systems is that they can often manage various dependencies for you, and essentially say to you, "Hey, you are about to install X, did you know you will need Y to make that work? You wanna install that too?" I'm guessing from your question you already have a general sense of a package management system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |