[GSoC 2017] Community Bonding

[Rainer Müller]

On 05/25/2017 09:27 PM, Umesh Singla wrote:
>     > About the project, so the `restore`, `snapshot` and `migrate` actions
>     > are going to the action_array list [1]. While the flow was made clear
>     > in the proposal, I think the first step should be to decide on an
>     > exhaustive list of arguments/flags these 3 actions can possibly take.
>     > This will help to design the procedures.
>     >
>     > Also, should we keep the code in a different Tcl script migrate.tcl
>     > like `reclaim`?
> 
>     I would prefer that, yes. You'll just need
>       package provides macports 1.0
>     line at the top and then you can write code as if it was in
>     macports.tcl. Alternatively, you can do what reclaim.tcl does and use
>       package provides migrate 1.0
>     and add 'package require migrate 1.0' in macports.tcl.
> 
> 
> Since we are planning on 3 different actions which can also be used
> independently like snapshot and migrate, having 2 scripts in the macports1.0
> directory directly or keeping these 2 commands in a single script doesn't seem
> to be good from design pov. We can have a separate folder for new (upcoming)
> actions with a hope that the existing code be split into "action" modules over
> the time.

Not sure what you mean with "a new folder" here.

The macports 1.0 package is the public MacPorts API. Every feature should be
reachable from there. If you think separate files make more sense, split them
into multiple files (as done with reclaim.tcl or diagnose.tcl).

It sounds logical to me to keep snapshot and restore together, since they will
export to/import from the same data format. Migrate could be in its own file.

As a side note, while 'port migrate' seems important enough for a new port
action, aren't the former two only useful together? Then I would expect the
functionality in the same port action, such as for example:

  port snapshot --create
  port snapshot --restore

>     Yes, the testing is not trivial at all. It might make sense to work with
>     mocking a lot here (e.g. overwrite functions that would usually be
>     called by your code to do nothing). That would allow you to run tests
>     without actually changing your system or doing a lot of environment
>     setup.
> 
>     Fortunately Tcl makes this quite easy because you can change any
>     function definition at runtime. 
> 
> 
> Is there anything even sacred to Tcl? Till now, it looks like you can just use
> anything in the language with pretty much anything else. This calls for a new
> blog post. And planning to discuss on the testing part in next email.
> 
> Also, can we have a small README with two to three lines kept in every folder in
> the base code at least? That'll be actually very helpful. 

I am not convinced separate README files make sense instead of a single
consolidated documentation at one place. If I do not know where something is
implemented, how would I find the correct directory with the README to look at?
A single document seems easier to search and skim through to understand the
structure.

Developer documentation is somewhat shattered across multiple places. Some
information and pointers to the wiki are in HACKING at the top-level, while
other stuff is also in the guide [1]. If unsure, about anything please just ask.

[1] https://guide.macports.org/#internals

> Also, I tried StackOverflow but does tclsh support all bash commands?

There are different modes in which tclsh can be used.

In interactive mode, tclsh will fall back and call external binaries when no
proc or builtin exists with the name of the command you tried to run. This is
similar to the behavior of normal shells like bash. However, this will not
happen in non-interactive use, i.e. when interpreting a script (as in running
the port(1) command).

Rainer