Recursive dependencies, recursive uninstall, variants

[Shreevatsa R]

On Mon, Apr 28, 2008 at 12:07:29PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote:
> Shreevatsa R wrote:
>> On Sat, Apr 26, 2008 at 04:20:13PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote:
>>> Shreevatsa R wrote:
>>>> Hi MacPorts developers,
>>> Hi,
>>>
>>> This looks good. Of course the output could be a lot better... And how 
>>> are you dealing with ports appearing multiple times? E.g. portA depends 
>>> on portB and portC, and these two depend on portD. If portD depends on a 
>>> lot of other ports you get a long list - twice. Don't know if that can be 
>>> improved in the ascii output...
>>
>> That's what I was using the global variable $shownports for -- to avoid
>> displaying, and recursing on, portD after the first time.
>
> Which is a bit unexpected. At least we should mark this port because the 
> real tree is already in the output above. Otherwise one could read this as 
> "portD has no dependencies".

Yes, that output format was some random compromise between a plain list format
and the fully informative DOT format. (And the new code I sent doesn't have
that output format.) So it's not relevant now.

>> Now, if `port dag --dept-list portA` were guaranteed to return a list of all installed
>> dependents of portA in topologically sorted order, then `port uninstall 
>> $(port dag --dept-list portA)` would Just Work. (Of course, I
>> don't care about the syntax, it could be `port uninstall --follow-deps portA`,
>> all I mean is that a reusable function for dependencies or dependents would be
>> useful.)
>
> No need for an extra function, just sort the list for port uninstall in 
> topological order before beginning to uninstall. The real problem here is 
> the implementation which just uses foreachport in the given order from the 
> command line.
>
> And maybe don't error out completely if a port is not installed...

Yes, here is what I think the behaviour of uninstall should be: Since one
cannot possibly uninstall without following dependents, make it follow
dependents by default. So when given a list of ports, it exhaustively finds all
dependents of all of them, and then does a topo-sort on this entire list,
informs the user which ports it is going to uninstall, and asks for
confirmation (if the list is bigger than the user's original list, say).

>> Here is some code; consider it proof-of-concept. It would be good if someone
>> can tell me what changes to make and what to do to get it committed.
>>
>> This is how it works now (I'm using "dep" for dependencies and "dept" for
>> dependents.)
> >
>> ~$ port dag --dep-list glib2
>> glib2 pkgconfig gettext expat libiconv ncurses gperf ncursesw
>
> So why a new target again...? We already have `port deps' and `port 
> dependents' and these two should be improved instead of rewritten with a 
> new name.

Sigh. I said above that I don't care about the command, and consider it
"proof-of-concept". This code was just to demonstrate that it is possible and
easy to have operations work on the entire DAG, and I used a new command
because I didn't want to touch existing ones. The reason is:

1. I'm sending code over email for someone to use / comment on, and it's more
convenient to paste new code than to indicate modifications to existing code,
since I'm not working with version control or anything, 

2. The existing commands have a lot of code that shouldn't be in them, such as
generic 'searching for ports', and UI, that should rightfully be in another
function, etc. I don't want to add to the mess.

The actual command that the user sees can be whatever you want; I was just
submitting the "functionality" and seeking comments on it.

You must realise that my situation is not the same as that of a committer, who
can simply do the right thing, clean up code, move it where it belongs, etc. :)

Thanks,
Shreevatsa