GSoC 2014 - Interactive Port Command and

[Clemens Lang]

Hi Marcus,

On Tue, Feb 25, 2014 at 11:18:27PM +0000, Marcus Santos wrote:
> I already started to read the Tcl tutorial on GSoC’s page and I would
> be grateful if you can help me to learn more about the project.

The Tcl tutorial is certainly a good start, as is learning a little
about Portfiles and how they work from https://guide.macports.org.

Regarding the interactive port command proposal:
There currently are some places in MacPorts where a user action is
aborted because of a conflict that needs to be resolved manually. Since
there is no API to communicate with a user (and ask for decisions or
approval), MacPorts usually just errors out in these cases, printing
some instructions on what to do next.

To understand why this is a problem (and the code that does that can't
just print a message and wait for user input directly) you need to be
aware of some of MacPorts' architectural principles: The port(1) command
you actually use when giving MacPorts commands is just a frontend for
the macports1.0 package, which really is the core of MacPorts. This
package knows about Portfile, where they are and how they need to be
run; it creates Tcl slave interpreters, resolves dependencies, runs
Portfiles, etc. Another vital part is the API offered to Portfiles (i.e.
all the commands that can be used from a Portfile), which is contained
in the port1.0 package. In theory (that hasn't happened so far), port(1)
is only *one* possible client for MacPorts. All interaction between
port(1) and macports1.0 should also be possible from a MacPorts GUI for
example (note that there are some GUIs available, but to my knowledge
none of them works using that principle).

Your job would thus be to draft and implement an API extension for the
interface offered by the macports1.0 package to allow asking the user
questions and waiting for user feedback, possibly using a series of
callback functions. The recently added progress bars [1] might give you
an impression how that can be done.

Your job would also be to identify places where interactivity would make
sense and implement it there. Three examples come to mind immediately:
 - When trying to install a port that conflicts with a port you already
   have installed, ask the user whether the conflicting port should be
   disabled.
 - When trying to install a port but one of the files installed by this
   port is already present, ask the user whether the file should be
   overwritten.
 - When a user tries to install a port, display a list of ports that
   will be installed as dependencies and ask for confirmation (unless
   there aren't any dependencies to be installed), like apt-get does.
Keep in mind that for non-interactive invocations (i.e. port(1) running
without being connected to a TTY) should still work just like before.

If you have any further questions, feel free to ask right away -- after
all communication is pretty much half of what GSoC is about :)

[1] http://trac.macports.org/changeset/117044
    http://trac.macports.org/changeset/117045
	http://trac.macports.org/changeset/117046
	http://trac.macports.org/changeset/117186
	http://trac.macports.org/changeset/117219
	http://trac.macports.org/changeset/117231

-- 
Clemens Lang