GSoC 2014 - Interactive Port Command and

[Marcus Santos]

Hi Clemens,

Can you help me with some questions I have about base/src/port/port.tcl and base/src/macports1.0.tcl?

First of all I need to understand how they work together and what is the role of each one. I have been around the code of the progress bar to understand how it works and trying to realize how can I do the interaction between the user and macports, and where to assess the input from the user. Second, how can I use the interface of macports1.0 to allow asking user questions?

Thanks in advance,
Marcus Santos.


No dia 28/02/2014, às 10:12, Clemens Lang <cal at macports.org> escreveu:

> 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
>