A Plea to Reduce Dependences (e.g., for swig)

[Jordan K. Hubbard]

On Aug 24, 2011, at 12:06 PM, Ryan Schmidt wrote:

> And I think we all know that Apple prides itself on producing software that has *few* options. Apple does *not* add an option to iTunes or iOS just because one power user thinks it might be fun to play with. Apple provides default functionality that is correct for maybe 80% of users, and a few carefully-selected options for maybe another 10% of users, and tells the remaining 10% tough beans. And this is great because what happens otherwise is that inexperienced users get overwhelmed by settings and choices they don't understand, or they select options without understanding their consequences.

Hi Ryan,

I cannot disagree with your overall sentiment.  Adding another option for "use system bits" would almost certainly create a combinatorial explosion of different user scenarios and make debugging and "tech support" for MacPorts even more problematic than it is now.

I guess, then, that this is really an appeal to hide the details since you can only get away with doing things "the Apple way" if you also hide the majority of the working parts from the end-user.  In MacPorts' case, this would essentially mean having a GUI tool which allowed one to click away on various packages to one's hearts content and then click "Go!" and have all the right deps installed transparently and with a minimum of download and CPU resources consumed.

Until you have that, however, then the "few options" defense just doesn't work for you because that's not what MP provides, or anything even reasonably close right now.  Right now, it's a build tool created for experts by experts (and sorry, but anyone who knows how to open Terminal.app and type shit is an "expert" by the Apple definition).  The experts see all of the machinations and the extra bits being installed and then they go blog about how Homebrew is the future of package management for Mac OS X. :-)

And before anyone says it, yes, I know that Apple is currently assisting the project in creating just that sort of binary package delivery infrastructure, and I really hope the effort succeeds since god only knows how much even I am tired of listening to myself harp on that particular topic, I'm just saying that MacPorts is currently at that "awkward age" where it's neither fish nor fowl, and that means that you really can't wrap yourselves in the clothing of "ease of use" just yet.  Keep that argument warm for when it's actually applicable though, yes, indeed. ;-)

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110826/152698a1/attachment-0001.html>