Is it worth persevering with Macports_Framework?

[Ian Wadham]

On 13/02/2013, at 12:06 PM, Jordan Hubbard wrote:
> On Feb 10, 2013, at 8:13 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> 
>> I heartily agree with you that "wrapping basic commands" is not enough.
>> I particularly hate GUIs that wrap basic programming and then pass
>> through base-level error messages ---unedited and out of context.
> 
> Just to riff on this a bit - it IS possible to design to a goal somewhere in between the "ideal" of Macports_Framework being a complete "API" for MacPorts' internals and just calling system("port install bletch") and hoping for the best as you attempt to parse an undisciplined stream of text flying out of the shell.
> 
> What you do instead is add special text markers to port(1) which it emits when called in a special "slave mode" from a GUI (or, for that matter, a batch build wrapper doing macports builds for a Tinderbox server).   Those let you differentiate different build phases and also separate "normal build output" from errors, all without having to know more than what text markers to look for.   Hugely elegant it may not be, but it works - I know because this same approach has been used by numerous "GUI wrappers" for Unix tools over the years, the most successful ones using this technique.  It's probably how XML was ultimately invented. :-)

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.

From a GUI point of view, you can do as Guido Soranzio's "Guigna" app does and
pass everything through a real Terminal window, unedited and unparsed (if there
is such a word).  Or it would probably be enough for an end-user to know:

    1. Has the action finished?
    2. Did it succeed or fail?
    3. If it failed, what are the error messages?
    4. If he/she cannot understand what went wrong (e.g. service provider's server
        is down), can messages and logs be made easily available for an email to
        macports.users or for submitting a ticket?
    5. If port(1) is taking a long time, what is it doing, what remains to be done and
        what has it done already?  IOW, should he/she kill it now or wait till he/she
        gets back from that urgent dental appointment?

I think it may be possible to get all of that from port(1) without very much parsing.

The idea of putting markers in port(1) outpu is nice.  If that became necessary,
would patches for review be acceptable to Macports developers?

Cheers, Ian W.