Given some applications that can be installed natively as well as through MacPorts (such as MacVim, iTerm2, Gimp, etc.), what are pros and cons for choosing one installation method over the other?
closed as not constructive by patrix♦, Gerry, Mark, Michiel, bassplayer7 Nov 6 '12 at 22:08
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
If the developer releases pre-built binaries for your OS, then this will likely be the quickest, easiest and most up-to-date (in terms of the application itself) method of getting an application. This relies on the developer (or some trusted third party) to be keeping the builds up to date with changes in both the application and in Mac OS X (e.g. rebuilding against the latest Mac OS X SDKs as they are released).
One downside is you are trusting whoever built it not to have maliciously modified the source before doing so, and/or whoever is hosting/mirroring the download not to have done the same. Generally a non-issue, but that's why there are often MD5 checksums for downloads.
A possible downside is that you don't have control over which version of any dependencies the developer builds against (e.g. for things like Python, or the C++ STL, or OpenSSL). For example, if they build against native Mac OS X SDKs, these are generally a little behind the current versions of most libraries. They do get updates, but not necessarily very quickly (except in some critical security situations), as Apple need to do their own QA/testing before they can include updates to libraries they bundle with the system.
Some developers may include the latest libraries in their application bundle, especially if they rely on new features of said library which haven't yet made it into the base Mac OS X set. Basically, you can't control this, so it may/may not be a downside.
Building from Source Manually
This might come under 'installing natively', since its not macports as such, but basically means getting the latest source, and building it yourself against 'native' Mac OS X SDKs and/or your choice of versions of dependencies.
Advantages are that you're going to be building on your system, for your system, so all dependencies match your runtime environment and are the version of your choosing (e.g. recently updated to latest source to include bug fixes and security patches). Of course the obvious downside is you need to make sure you have all those dependencies (YMMV depending on the project).
You're also not needing to trust someone else's binary build (though you still want to make sure you've got the 'official' source code, without any chances of malicious modifications!).
Compared to installing from binaries:
Installing from MacPorts
This is typically much like building from source, but much of it is scripted and tested by thousands of others, so you tend to have fewer issues getting projects to build. Further, MacPorts keeps track of all the projects you build, and their versions, and makes it really easy to check what's out of date, upgrade to new versions, switch between versions, etc.
Of course you're relying on the application/dependencies to be in MacPorts, which requires someone (possibly even you!!), to have made a MacPorts project for it. Also you're relying on the MacPorts project to be kept up-to-date with the original application, and likewise for the dependencies. If the MacPorts scripts aren't updated when new versions of the source are released, you won't get access to them.
Compared to Installing Natively from Binaries
Compared to building from source yourself
Installing natively is often easier, but sometimes you have to wait a bit longer to get the latest version.