GSoC'17: Add migrate action to port command Project

[Mojca Miklavec]

Hi,

I'm not too familiar with the project, but just some of my thoughts.

One of the biggest pains at the moment is the fact that we don't
record requested variants anywhere. We do record requested ports, but
not the variants.

It may easily happen that "port install foo" would install variant A
on one OS version and variant B on another. If you just record all the
variants, the user might end up with variant A installed on the new OS
even if he never requested it.

I don't know whether that fits anywhere within the scope of the
project, but I would find it super useful if one of the side products
of the project would be extension of the SQL table that would also
record +requested and -excluded variants.

It might be slightly tricky to properly cover all the corner cases.
One might run
    "sudo port install foo -x11"
where "foo" depends on "bar" ("bar" will not be requested and doesn't
even have option x11) and "bar" depends on "baz" ("baz" will also not
be requested, but will have the option x11 that perhaps(?) needs to be
disabled).

That is: at least having that info available would already be a huge
benefit. If "sudo port upgrade outdated" would take that info into
account ... so much better.

I don't want to distract you from the goal of the project, but if
talking about upgrades etc, taking a bit more care about the variants
seems relatively important to me.


***


I would like to see one more scenario covered if there is sufficient
time. When users change some setting in their macports configuration
(I have https://trac.macports.org/wiki/LibcxxOnOlderSystems in mind,
but there might be other cases), it would be super helpful if users
with a working MacPorts installation could run
    sudo port <something>
which would:
- remember which packages are installed
- deactivate all of them (and perhaps move the files to some temporary
location just in case they are needed again)
- reinstall the same packages using the new settings

Basically the same scenario as with regular migration, except that the
user would not upgrade the OS, only some of the basic macports
settings (OK, I'm not sure how exactly you planned to implement the
migration tool, I'm just speculating).


***


I cannot comment on Bash vs. Tcl, but I imagine that quite a bit
should be done in Tcl.

Some example of mixture of Bash and Tcl that come to my mind:
    https://github.com/macports/mpbb
For example the code that prints variants:
    https://github.com/macports/mpbb/blob/master/tools/canonical-variants.tcl

(Don't bother trying to understand what that does. Just that one can
write some Tcl script that uses MacPorts "API" even if you use a
completely different language from the outside.)


***


Just curious: how exactly does Xcode affect this project?

Mojca