RFE: Option to compute recursive deps

[gwhitney@…]

Currently the "deps" target only lists the immediate dependencies of the given port. It would be very useful to see a list of everything that would be installed in order to install a given port. This could either be a flag to deps or a separate target, e.g. either

  port -r deps emacs-devel +x11

(where -r for recursive deps has a nice symmetry with -R for recursive dependents in upgrade) or

  port recdeps emacs-devel +x11

I think there are some notes on the mailing list suggesting similar things, but I searched and could not find a ticket for such a thing. My apologies if this is a duplicate.

[gwhitneycom1@…]

Somewhat hackish patch providing this functionality

[gwhitneycom1@…]

new file portdry.tcl which needs to be added to port1.0 directory for this patch

[gwhitney@…]

OK, the attachments provide an example implementation of a "dry" target which thereby provides the desired functionality -- the recursive dependencies are those processed in a "dry" run. The patch applies to 1.4.3 as distributed (sorry I'm unclear how to get to the head version, port selfupdate won't do that, will it?) Example outputs:

$ port.hack -f dry emacs-devel     
--->  Processing ncursesw (doing nothing, dry run)
--->  Processing ncurses (doing nothing, dry run)
--->  Processing emacs-devel (doing nothing, dry run)

and

port.hack -f dry emacs-devel +x11
--->  Processing jpeg (doing nothing, dry run)
--->  Processing zlib (doing nothing, dry run)
--->  Processing libpng (doing nothing, dry run)
--->  Processing libungif (doing nothing, dry run)
--->  Processing ncursesw (doing nothing, dry run)
--->  Processing ncurses (doing nothing, dry run)
--->  Processing tiff (doing nothing, dry run)
--->  Processing emacs-devel (doing nothing, dry run)

There are a few minor issues which make this patch not quite ready for prime time:

1. Note the -f options in the commands above; doing a dry run does have the minor side effect that port remembers the selected variants, when in fact ideally "dry" should leave the entire port system in the same state when it's done as when it started
2. Although the whole thing turned out to be relatively easy and modular due to the portXXX.tcl architecture, special rules about "dry" are hardcoded in this patch in probably a few more places than would be ideal. Probably someone with a better overall familiarity with the code could see ways to eliminate several of the hardcoded bits.
3. This version just assumes it has to process all the types of dependencies, which means that this is basically a "dry-install". It could be named as such, rather than just "dry", for clarity. A fancier alternative would be to make dry into a -y option which uses the original action to extract the desired dependency types (depends_lib, depends_run, etc) and then automagically changes the action to dry. (e.g "port -y build fooport" or "port -y configure barport") I'm sure the core design/developer group can make a better decision on such syntax details than I can. I programmed a single "dry" target that means in essence "dry-install" because that seemed the most straightforward and easy to use and understand without sacrificing much practical functionality.

Here's hoping that providing a patch which shows how essentially everything needed for this functionality is already present will help tip this over to a feature which actually gets included in a release in the near future. Sorry I'm not really familiar enough with the code to provide a patch that's truly ready to roll, but I think this is very close and I hope it helps.

In the meantime, I can use this as a local patch, I find it extremely helpful in understanding what's going on with ports -- but I'm unclear on how to make it conveniently survive "port selfupdate"s. (Any suggestions?)

Regards, Glen

[gwhitney@…]

Slight update: I have proposed on the macports-dev mailing list an enhancement to the dependency-specification scheme in MacPorts. That change would necessitate rewriting dry as an option, say -y. So if the response to my proposal is positive, I'll open a separate enhancement ticket with my proposed patch on dependencies, and then I'll update the patch here to add a -y option instead.

[gwhitneycom1@…]

much better patch for dry run, adds -y option so any target can be run dry

[gwhitney@…]

Further update: After thinking about my last comment, I realized how trivial it is to add a -y option that will make any command run as a dry run. This option suffers from none of the problems of the original patch, plus it's much smaller and simpler. It would not interfere with any change to dependency structures, were one to be made. In my humble recommendation, I believe this patch would be an improvement in the functionality of "port" and is consistent with the current codebase. I look forward to your consideration on committing it.

[gwhitney@…]

slight further improvement: don't write variants into statefile in a dry run

[gwhitneycom1@…]

update patch to r25303

[gwhitneycom1@…]

Oops, port -y upgrade could still take a few actual actions. This fixes it, now applies to r25313

[gwhitney@…]

Although as far as I know this patch still works just fine as far as it goes, in thinking about testing (as a newly-minted committer) it occurs to me that there are two possible functions for this "dry run" facility. One is simply to see what ports will be "touched" by a given action -- this is the connection with the original RFE, an option to compute recursive dependencies. But another level of "dry run" one might want is to display the exact list of operating-system commands that would be executed if the command were run, without actually executing any of those commands. That can be a powerful debugging tool, to see exactly what would happen, without it occurring. It could also be useful for writing regression tests: execute a complex dry run and verify that the generated sequence of actions is correct.

I will try to discuss these options on the macports-dev list and see what types of dry run are wanted and what the syntax should be. So I assume that in the meantime there's not much point in checking this patch in, until the "final" design for the option is reached.

[jmpp@…]

Milestone Needs developer review deleted

[jan.matousek@…]

Cc Me!

[jmr@…]

Any news on this?

[olfway@…]

Cc Me!

[kngspook@…]

Cc Me!

[kngspook@…]

Cc Me!