Hi,
On Thu, 2 Apr 2020 at 20:37, Joshua Root wrote:
>
> I would say it's OK for a GSoC project to be completely original and
> never discussed before; the problem with this one is just the scope. You
> would need to spend the entire summer (if not more) just doing design in
> order to do it right, but the primary assessable output of the project
> is code. Naturally you need to do some design before you code, and other
> tasks like documentation of the code, but you need to write the code.
>
> It's also OK for a GSoC project to have research elements. A successful
> project may produce code that never actually gets put into production --
> maybe in the course of implementation it becomes clear that the entire
> approach is flawed. Learning that is still valuable.
>
> In this particular case, if the student can suggest a subset of the
> project with a small enough scope to be completed over the summer, that
> will still produce working code, it could be considered. I have no idea
> what that would look like, but it may be possible. As Ryan implied, an
> important question is "Which parts should be rewritten in Python, and why?"
>
> - Josh
I just want to say that I completely agree with Josh here.
I would love to see MacPorts (re)written in Python, this has been my
wish since years, but I realize that I neither have sufficient
expertise nor time to do it (I guess I could gain the expertise, but
that would again require insane amounts of time). And it's not like we
have an army of developers willing to do this at this very moment, but
if it was written in Python (in a nicely structured way), I guess that
the number of contributors to base would grow quite a bit.
I would say that the main reason why this hasn't been discussed (loud)
before is that developers understand how much work this is, and it
takes quite some expertise and quite some work to get it done right.
And rewriting is probably even more challenging than writing it from
scratch, since one would want to keep compatibility with the existing
packages, and ideally reproduce the exact same results. (We did in
fact discuss this during the last meeting, but not as realistic to
happen any time soon.)
But it's not entirely impossible to do it either. I mean ... MacPorts
base has been written at some point. HomeBrew has been written at some
point. Plenty of other package managers have been written from scratch
at some point. I would not dismiss the initial effort as a GSOC
project as long as the student can prove the competence to do some
good work and reasonable potential to stick with the project
afterwards. GSOC could be done partially as a research project. But
it's of course critical to have a very good student working on this.
If we would ever want to have the base rewritten (independent of
whether or not it happens in the scope of GSOC) and not want to end up
with yet another competitor to MacPorts, we would want to keep the
Portfile syntax working (one could later remove some hard-core tcl
from ports if there was an alternative to achieve the same). One could
potentially start with using Python to add useful new functionality
that's still missing and is either very annoying to write in Tcl, or
has a bigger contributor potential if written in Python; we could for
example support something like "port health " that would
fetch the data from the web api and report to the user whether the
port and its dependencies are know to build or break, whether there
are any critical bugs open in Trac, ... (just as a random example).
Some further action could later be replaced step by step, and in
parallel some bottom-up design would need to be built in Python to
slowly migrate over. (I'm not competent enough to mentor such a
project though.)
It's definitely not an easy task, but if the student can prove
competence to solve some problems in a superior way ...
Mojca
