[GSoC 2017] Community Bonding

[Umesh Singla]

Hi



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


>
> If you need any additional special SQL queries, that can be done, yes.
> There should be abstractions available in Tcl already so that you don't
> have to deal with SQLite's C API directly, though.
>
>
The cregistry folder seems to have most of the sql queries implemented and
to deal with the registry database, I'll only have create, update and
select queries to do, so looks like I won't have to deal with C. I went
through an entire "port uninstall" example to see how from Tcl gets to
sqlite C through registry, so things seem a bit clear than before.


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

As Clemens suggested on IRC, will start with an *honest* short daily log of
the work like what I did for the project and what I did related to MP etc
from today onwards.

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


Regards,
Umesh Singla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170526/4bf4d101/attachment.html>