On Apr 1, 2020, at 18:20, Ryan Schmidt wrote:
> On Mar 31, 2020, at 16:14, Alex Ionkov wrote:
>
>> I submitted a proposal this year for rewriting parts of MacPorts in Python.
>> The eventual goal is to rewrite all of MacPorts in Python to increase
>> modularity and make integration of other APIs with MacPorts easier.
>
> Is this an idea you just came up with or has there been some discussion of
> this before? I didn't see this idea on our GSoC page [1] and it comes as a
> surprise to me.
>
> [1] https://trac.macports.org/wiki/SummerOfCode#Projects
I see now that it is actually on the list, as just a one-line item:
https://trac.macports.org/wiki/SummerOfCode?action=diff=337_version=336
So then my comments are not so much about your proposal, Alex, as it is about
the fact that this item got onto the list at all.
MacPorts has 18 years worth of Tcl code which not even us long-time MacPorts
developers fully understand. It works as is, and in the spirit of not modifying
a working system, my inclination would be not to change it. I may not know
where everything is or how everything works in MacPorts base, but I know where
many things are and how many things work, and I fear that knowledge would be
lost if it were rewritten. Certainly we should fix bugs. Certainly we should
make incremental improvements like whatever is necessary to allow us to update
to Tcl 8.6 (i.e. fix the "catch" problem). But rewriting MacPorts wholesale in
another programming language seems completely infeasible to me.
I'm sure that rewriting MacPorts base would introduce new bugs, and I'm not
confident that our existing test suite would be adequate to catch them. In
fact, our test suite is written in Tcl, so there's double the possibility of
missing bugs: either because the test suite didn't cover a particular scenario
or because rewriting the test suite in Python introduced new bugs into it.
It's not just rewriting MacPorts base either. The more than 10,000 portfiles
and the portgroups are also written in Tcl. Should they all be rewritten in
Python as well? Doing that manually would take colossal effort, and doing it
automatically would require writing a fairly full-featured Tcl-to-Python
converter. Or if you propose that the portfiles should be kept in Tcl, then
that means Python would have to launch Tcl to interpret each portfile, which
seems unnecessarily more complex than what we have now. Using yet another
programming language in MacPorts makes it that much harder for new developers
to get up to speed.
Note that Tcl was deliberately chosen because of its simple syntax. If we
convert portfiles to Python, would that make basic everyday usage more verbose
and if so do we really want that? As one specific example, setting the name of
a port to "foo" is currently as simple as writing:
name foo
If portfiles become Python files, I am guessing that would have to be rewritten
as:
name = 'foo'
and that kind of superfluous punctuational verbosity is what the original
designers of MacPorts were trying to avoid.
There are also a lot of little utilities in the macports-contrib repository
that hook into MacPorts via Tcl. Our buildbot setup uses several more such
scripts developed just for that purpose. All of these would then need to be
rewritten in Python.
Needless to say, this also requires a thorough understanding of Python, both to
perform this massive one-time conversion and then on an ongoing basis by all
MacPorts developers and maintainers. Maybe many people are already familiar
with Python, but some MacPorts developers like myself are more familiar with
Tcl at this point. Perhaps we could all retrain ourselves to learn Python. But
I can't help but recall how four years ago we undertook the massive conversion
of our source code from Subversion to GitHub, from which I still haven't fully
recovered; I still can't contribute to MacPorts as effectively anymore as I did
when we used Subversion. I'm probably in the minority there as other developers
were already familiar with git at the time, and if everybody else wants
MacPorts rewritten in Python and it can be done then I won't stand in the way.
I don't recall any of this discussion occurring on the mailing list before. I
usually stay away from Google Summer of Code issues, but I would have hoped
that GSoC would be used as an opportunity for us to finally implement changes
that we have wanted to do for years but never got around to doing, rather than
to propose new projects whose ramifications have never been discussed before.