NonTcl Portfiles

George Armah armahg at
Mon Jul 21 05:26:22 PDT 2008

On Sun, Jul 20, 2008 at 7:00 PM, Jordan K. Hubbard <jkh at> wrote:

> Now you're just talking crazy talk, George! :-)
> Seriously, we we have looked at this a few times in the past (in response
> to the "everyone hates Tcl" as well as other concerns) and debate generally
> seems to polarize around two positions:
> A)  Tcl, with its simplistic and context-sensitive syntax, is already far
> more of a textual format than a structured language.  Just make the various
> verbs and nouns in the macports infrastructure a bit more descriptive, clean
> things up here and there, done:  A description format that's 90% "option
> value" and 10% high level functions that could read more like english if
> that was really the goal (Note:  I just made those numbers up - it could be
> substantially more options and less functions with certain design
> decisions).  No need to create yet another "user friendly" description
> format.

I did notice that whilst reading the guide. The portfile itself IS very self
descriptive. In fact i'm a sure some of the Tcl apprehension stems more
from the fact that newcomers will be encountering the language for the first
time, rather than from any actual "difficulty" in the portifile creation.

> B) Tcl is totally NOT machine readable by anything but a Tcl interpreter,
> something which makes data harvesting and/or mass-changes across the ports
> collection really really painful.  It is time for Portfiles to be written in
> XML with a proper DTD!  We can use translators to get to and from a human
> readable format when and if editing is actually required, so don't be such a
> bunch of sissies, running away every time the letters X, M and L are
> mentioned together!
> Since no battle like that can ever truly have a clear winner (they're both
> "right" for some value of "right"), we generally decide in the end to just
> leave things alone, which is probably the right decision for this iteration
> of MacPorts.   If we ever do see such a sweeping change of the collection, I
> think it will be because someone decides, one day, to write MacPorts "3.0 or
> later" completely from scratch.   New Portfile syntax, new infrastructure to
> go with it, and probably some monster Perl script (in Perl6, of course)
> which manages to convert some significant percentage of the old ports into
> the new format.

So basically it would be a hefty change requiring lots of time and
resources. I get that. The driving factor behind my suggestion however was
getting more people to contribute to the project. From your comments,
allowing more than one file format  does not seem like a good

I just started reading more on MacPorts Web Application. Its goals are
exactly what I had in mind when made this suggestion :).
I guess this thread can end  and hopefully we'll have  something up and
running after SoC.

Thanks for enlightening me on the Tcl argument though,

> - Jordan
> On Jul 20, 2008, at 3:38 PM, George Armah wrote:
>  (First two attempts at sending this email failed. Hope this one works)
>> Hello,
>> I was reading through the Portfile Development section of MacPorts Guide
>> and an idea occurred to me.
>> It has been mentioned before that having Tcl as MacPorts' base language
>> does shy away some potential developers and port contributers /
>> maintainers.
>> The Basic Portfile example (or some variant of it) looks like something
>> that could easily be typed in a plain old text file. Would it be possible
>> to create a Tcl
>> tool that parses Portfiles that are in for example .txt file formats? The
>> exact format of the text in
>> the file would probably be different from the current Tcl portfiles (and
>> hopefully simpler as a
>> result).
>> That way potential port maintainers who don't know any Tcl won't shy
>> away from contributing and maintaining ports.
>> I myself don't know too much Tcl (but am willing to learn) and currently
>> have my hands full with GSoC. I'll however be willing to work on such a
>> project after
>> summer is over if I have some help getting started.
>> Let me know if this idea sounds feasible or if there is already such a
>> tool out there which I didn't know about,
>> Thanks,
>> George.
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the macports-dev mailing list