How to get a full list of dependents?

[Ian Wadham]

On 10/02/2013, at 7:37 AM, Joshua Root wrote:
>> Apparently commands such as "port dependents xxx" or "port echo dependentof:xxx"
>> will only list *installed* dependents --- and "xxx" must itself be installed.
>> 
>> How can I get a full list of ports that are dependents of "xxx", whether or not
>> they or "xxx" are installed?
>> 
>> ATM I would like to see which ports depend on Growl and which depend on
>> MacPorts_Framework.  Pallet depends on both, but are there others?
> 
> port echo depends:Growl
> 
> This uses the index, so it won't find dependencies that are added in
> non-default variants.

Thanks, Joshua.  I can't see it in "man port", though :-)

>> If I wish to make a change in MacPorts_Framework, what might be the impact
>> on ports other than Pallet, or is Pallet the only user?
>> 
>> Ditto, if I wish to remove the dependency of Pallet on Growl?  Do other ports
>> use it successfully?  It is apparently not doing anything in Pallet.
> 
> This (and other questions regarding development of Pallet and
> MacPorts.framework) is probably more suited to the macports-dev list,
> where you'll get the attention of more developer types.

I will, if and when I am ready, but I am still a newcomer in these parts,
previously (and still) in C++, Qt and KDE.

> MacPorts_Framework is still in a pretty "pre-alpha" state, so I wouldn't
> worry too much about maintaining compatibility if not doing so will make
> it better. Just make sure you mention the interface breakage in the
> commit logs, and fix Pallet to match.

It looks as though backwards compatibility is an impossible ask in an Xcode
environment.  For starters, there are all the .xcodeproj files.  My Xcode 4.6
grumbles about them all the time and FAIK has already changed them a lot.
The files in SVN are for Xcode 4.3, I think.

Then Xcode keeps "pushing" newer features that are somewhat
fundamental, such as automatic reference counting and Interface
Builder layouts with constraints.  These are nice features, but not
backwards compatible.

Re the "pre-alpha" state of Macports_Framework, tell me about it … :-)

One problem is that there is almost zero error information (in an NSError
object) passed back to Pallet, but lots of "comments to self" in the code
about the need to do something.  Another problem is that Pallet ignores
the NSError object anyway and treats all actions as successful.  A third
is that actions like "install Growl" should always fail (the Growl port is
broken), but sometimes are said to "succeed" (in the Console messages).

Macports_Framework has over 12,000 lines of code, and nearly 4,000
lines are a copy of Apple code for BetterAuthorizationSampleLib, dated
2007 (Is that code still current, I wonder?).

Should I persevere with Macports_Framework?  It's been a while since I
worked with threads and concurrent processes and Apple's way of doing
things, in Objective C, OS X and Xcode is all new to me.  I enjoy a challenge,
but in this case, is it (Macports_Framework) worth the effort?  People are
lukewarm about having a GUI for Macports anyway.  I am not, but I find
the framework for interacting with Macports to be huge and rather daunting.

> Growl support is good to have, but Pallet should still be usable without
> Growl.

I have commented it out for the moment … ;-)

All the best, Ian W.

P.S. Sorry about ranting OT ...