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

[Ryan Schmidt]

On Aug 27, 2011, at 04:55, Anders F Björklund wrote:

> Jordan K. Hubbard wrote:
> 
>> 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.
> 
> You could add a different ports tree (or several actually, one for each OS) like the original poster did with his ports. That's maybe not another globally confusing flag like +universal or +system_x11, but still something of a "fork" of the ports ? But I always thought that MacPorts was for when you got tired of the provided options and wanted to pick a few of your own... Maybe not.

The response to this suggestion has always been that we do not have sufficient human resources to maintain our one single ports tree that we have today; we certainly do not have the resources to maintain multiple divergent trees.


>> 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.
> 
> Unless somebody completes Pallet, the only working GUI would be Port Authority.

Pallet is complete, or at least, functional, as far as I'm aware (though I don't use it).

https://trac.macports.org/wiki/MacPortsGUI

Port Authority and Porticus are two other options.

https://trac.macports.org/wiki/FAQ#gui


> And that is still too technical for most users, since they don't want to hear about ports/packages but about apps/software. With icons. Big icons. <sigh> So it would need something more "App Store", first. Like what happened in Ubuntu, when the Synaptic tool changed into the Software Centre.

Two things. First, MacPorts isn't really for apps that have icons. Some of our ports are for apps that have icons, yes, but the vast majority are for command-line programs and libraries.

Second, MacPorts *is* about software. If a user wants, say, ImageMagick, they can "sudo port install ImageMagick". They don't need to care that MacPorts will install a bunch of other ports for them. In the end, the "convert" command will be installed in /opt/local/bin and they can use it, which is what they wanted.


>> 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).

I agree MacPorts is for experts today, and I agree we should continue to work on making it more accessible to non-experts, via improving Pallet or other GUIs, improving our web presence, etc. And in support of this long-term goal, we should continue our years-long practice of adding options and variants sparingly, and even removing some options users are unlikely to need, and possibly to not even understand. This is why I claim we should not add an option to build with system dependencies, nor should we fork the ports tree; these are distinctions that a non-expert user will not care about and probably won't understand, and it increases our maintenance burden and reduces the time we have available to make actually useful changes in MacPorts. And it's one more thing we'll have to either find a way to incorporate simply into a GUI, or to rip out again later. I disagree that "few options" is "not what MP provides"; I have certainly been campaigning against variant proliferation in my years with the project and will continue to do so. I've occasionally responded to patches users have submitted, where they've added variants for various ./configure flags, just because those flags existed; that's not how we do things in MacPorts; we don't add an option just because we can. And even if we aren't today at as few options as we would like to have, certainly the solution isn't then to add more options.


>> 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. ;-)
> 
> I'm guessing that *most* of the macports port installation complaints will go away now, with the packages.macports.org archives up ?

Most of the installation complaints that relate to ports taking a long time to compile, sure. Even most of the installation complaints relating to users installing random third-party software that mucks things up.