Is it worth persevering with Macports_Framework?

[Ian Wadham]

On 20/02/2013, at 11:43 AM, Jordan Hubbard wrote:
> On Feb 14, 2013, at 12:46 AM, Rainer Müller <raimue at macports.org> wrote:
>> The message classification currently happens through a handful of procs
>> such as ui_error, ui_warn, ui_msg, ui_notice, ui_info, ui_debug. These
>> add the prefix for errors and warnings and decide whether to print the
>> message at all based on the verbose, debug or quiet flag, -v -d -q,
>> respectively.
> 
> Right, that part is already well-segregated and easy to extend.  I think Ian's more concerned with:
> 
>> Yep. I think port(1) is quite good in that respect already, but messages arising from
>> builds are not.  Port(1) puts "--->" and "Error:" prefixes on key lines of  output.

Thanks, Jordan, I am currently looking along the lines of running MacPorts
commands as a Shell script in the background and collecting the stdout and
stderr in the GUI app as the script proceeds, filtering it (if necessary for the
kind of end-user involved) and displaying progress info.  With the help of
an Apple Tech Note I have worked out a reasonable way to do all this from
Cocoa, requesting an admin password in the normal Apple OS X way
when it is needed.

There will probably be no need to parse build-messages.  As I see it, it's
more of a need to tick off MacPorts stages as they proceed (for filtered
progress reporting).  I think those will be easy to identify and parse.  If
anything goes wrong during a MacPorts run, there wouid be a need to
recall error output for immediate troubleshooting or inclusion in an error
report (e.g. the details commonly asked for on the macports-users list
or in a ticket).

> I say "pipe or pty" since I'm not sure if a pipe would catch any and all types of subprocess I/O, but it probably would (and would be a lot simpler than doing the PTY allocation) so I'd try that first and just keep PTYs as a fall-back idea.

"port" commands as they stand might provide all the output I need.  A PTY
might provide finer control over I/O between the GUI and MacPorts.  Thanks
for the idea, Jordan.  For now, I am using a Cocoa/OS X NSPipe to listen to
the usual "port" command output in the GUI.

Cheers, Ian W.

P.S. Re the main topic here:
        We have not heard back from the authors of Macports_Framework and
        Pallet and I am tending towards using the "port" command and the
        PortIndex file as the only interface between a GUI and MacPorts, i.e.
        no Macports_Framework.

        I think this will offer a more loosely bound and future-proof interface
        than Macports_Frameworks, as well as being more general (i.e.
        extendable to other sources of FOSS on the Mac).

        Using the PortIndex file is not strictly necessary, but should be more
        efficient timewise than using "port" commands alone to retrieve data
        about all the available ports.