On 13/02/2013, at 12:06 PM, Jordan Hubbard wrote:
> On Feb 10, 2013, at 8:13 PM, Ian Wadham <iandw...@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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
