Is it worth persevering with Macports_Framework?

[Ian Wadham]

Hello everybody,

I raised this topic on macports-users under the subject "How to
get a full list of dependents?", but it is undoubtedly better to
discuss it here and under a proper subject line.

I have been studying the source code of Pallet and
Macports_Framework and doing a bit of testing of both, with
a view to developing a GUI for Macports.  I am using Xcode 4.6
and OS X 10.7.5 (Lion) on a Macbook Pro of 2011 vintage.

Please note that I am new to Objective C, Xcode and OS X, but I
have been developing in C++, Qt, KDE and Linux for a few years.
I am in charge of KGoldrunner, KSudoku, Kubrick and KJumpingCube
in the kdegames4 set.

It appears that Pallet and Macports_Framework are both ex-GSoC
projects that are not really finished.  Certainly they have a few rough
edges.  Joshua Root described it as a "pre-alpha" state.

On 10/02/2013, at 7:37 AM, Joshua Root wrote:
> 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.

I replied as follows.

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),
when you use Pallet to do "install Growl".

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.

I am happy about building a GUI for Macports and I hope it would be an
improvement on Pallet, but I am getting cold feet about Macports_Framework.
If I persevere, I could certainly use some help with it.

Also the question arises, does Macports, as a group, want to persevere
with Macports_Framework?  Apparently Pallet is its only dependent and
I would not say that either of the two ports is up to the standard of quality
we expect from Macports and the "port" command, not to mention the
hundreds of other ports in Macports.

Maybe it is a question of "fix or forget" Macports_Framework.

All the best, Ian W.