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

[Ryan Schmidt]

On Aug 20, 2011, at 21:30, Joshua Root wrote:

> On 2011-8-20 06:07 , Jordan K. Hubbard wrote:
>> 
>> Time for a re-think, or
>> perhaps even just the creation of some sort of modality such that those
>> who wish to live on the risky edge can set a switch (and advance
>> apologies if that switch already exists and I simply haven't noticed it
>> yet) and those who don't, or who need to support multiple versions of
>> the OS from a single tree (NFS-mounted /opt/local anyone?), can set the
>> switch to the other position.
>> 
>> Thoughts?
> 
> This is another one of those ideas that is fine in principle, with the
> one little catch being that it requires significant work, and nobody is
> putting up their hand to do said work.

It's not only the effort of implementing the changes. It's also the greater effort of supporting that change forever: handling user bug reports and questions about it. I've worked in technical support professionally, and I've supported MacPorts for years, so I can say with a certain amount of experience and confidence that having a few well-thought-out well-tested options is better than having a whole bunch of options: it means there are fewer things the user needs to think about, fewer opportunities for the user to screw up, and fewer cases the maintainer needs to test. I know I don't test all of a port's variants when I commit an update. Time and again I've seen bug reports about an obscure variant that doesn't work because it adds a patchfile that was not updated when the port was updated. Nor do I build ports for each possible build_arch, or each combination of universal_archs, on each version of Mac OS X we run on, with each version of Xcode and each available compiler. Each of these and the other settings and variants we already support exponentially increases the number of possible user configurations, and the number of opportunities for error.

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.

Right now, we know that MacPorts works, when pulling in all these dependencies people in this thread are so keen to remove. We could spend a lot of effort changing a lot of ports to use system dependencies, and find that it doesn't work for a bunch of ports, and we've wasted a lot of time. Or we could find that it works fine on the particular system we're on, with the particular ports we tested, and commit it and think all is good, until the bug reports start rolling in, from users on Leopard or i386 or with Xcode 3 or whatever other non-majority configuration. And especially if we do it by "just" creating a switch (in the settings, or as a variant) as Jordan suggested, which is off by default, then an average of nobody will be using it, which means those few who do use it will likely find problems nobody else has seen, which will lead to conversations like this:

User: I set this new setting in macports.conf and now these ports won't install.

MacPorts team: Yes, changing that setting can break things; you shouldn't have set that.

User: Why did you give me an option that breaks things?

Or perhaps even more likely:

User: These ports won't install (user doesn't mention the setting because they forgot or don't realize its significance)

Maintainer: Works fine for me, I don't know how to help you.