Hey Josh, Thanks for the input!
The CLI output has probably changed more than the API in the past. That's true, I actually hadn't thought about output changing, I only considered the input changing. Good point. This probably points to duplication of functionality between port.tcl > and Pallet. That would be better solved by sharing of code, perhaps in a > new front-end support library module. Yeah, there's definitely a good amount of code duplication between the two. However there's also a lot of code in there for setting up the Tcl interpreter, error handling for it, and all that jazz. Not really, parsing some arbitrary text is not easier than adding > another procedure to the bindings. Eh, depending on how you set up the parser it could either be the same, or possibly even easier. No progress callbacks > No interactive prompt callbacks Yeah, those would definitely be some of the downsides. All interactivity would more or less have to be simulated, and progress bars would definitely be trickier. No ability to implement features that the CLI doesn't have > Worse performance Ah, these are some good points that I hadn't really considered. Though I suspect that there are few features for Macports that would be GUI only, it's still something to keep in mind. Thanks for the input! :) -Kyle
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
