Opened 14 years ago

Closed 12 years ago

Last modified 11 years ago

#11892 closed enhancement (fixed)

RFE: Option to compute recursive deps

Reported by: gwhitney@… Owned by: gwhitney
Priority: Low Milestone: MacPorts 1.8.0
Component: base Version:
Keywords: deps recursive Cc: ryandesign (Ryan Schmidt), jan.matousek@…, jmroot (Joshua Root), olfway@…, 0xced (Cédric Luthi)
Port:

Description

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.

Attachments (6)

dry.patch (3.2 KB) - added by gwhitneycom1@… 14 years ago.
Somewhat hackish patch providing this functionality
portdry.tcl (319 bytes) - added by gwhitneycom1@… 14 years ago.
new file portdry.tcl which needs to be added to port1.0 directory for this patch
dry.2.patch (3.3 KB) - added by gwhitneycom1@… 14 years ago.
much better patch for dry run, adds -y option so any target can be run dry
dry.3.patch (4.0 KB) - added by gwhitney@… 14 years ago.
slight further improvement: don't write variants into statefile in a dry run
dry.4.patch (4.0 KB) - added by gwhitneycom1@… 14 years ago.
update patch to r25303
dry.5.patch (7.5 KB) - added by gwhitneycom1@… 14 years ago.
Oops, port -y upgrade could still take a few actual actions. This fixes it, now applies to r25313

Download all attachments as: .zip

Change History (23)

Changed 14 years ago by gwhitneycom1@…

Attachment: dry.patch added

Somewhat hackish patch providing this functionality

Changed 14 years ago by gwhitneycom1@…

Attachment: portdry.tcl added

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

comment:1 Changed 14 years ago by 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

comment:2 Changed 14 years ago by 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.

Changed 14 years ago by gwhitneycom1@…

Attachment: dry.2.patch added

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

comment:3 Changed 14 years ago by 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.

Changed 14 years ago by gwhitney@…

Attachment: dry.3.patch added

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

comment:4 Changed 14 years ago by pipping@…

Milestone: Needs developer review

Changed 14 years ago by gwhitneycom1@…

Attachment: dry.4.patch added

update patch to r25303

Changed 14 years ago by gwhitneycom1@…

Attachment: dry.5.patch added

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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by jmpp@…

Milestone: Needs developer reviewMacPorts base bugs

Milestone Needs developer review deleted

comment:7 Changed 13 years ago by nox@…

Priority: Nice to haveLow
Summary: RFE: base-1.4.3 Option to compute recursive depsRFE: Option to compute recursive deps
Version: 1.4.3

comment:8 Changed 13 years ago by nox@…

Milestone: MacPorts base bugsMacPorts base enhancements

comment:9 Changed 13 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added
Owner: changed from macports-tickets@… to gwhitney@…

comment:10 Changed 13 years ago by jan.matousek@…

Cc: jan.matousek@… added

Cc Me!

comment:11 Changed 13 years ago by jmroot (Joshua Root)

Cc: jmr@… added; gwhitneycom1@… removed

Any news on this?

comment:12 Changed 12 years ago by olfway@…

Cc: olfway@… added

Cc Me!

comment:13 Changed 12 years ago by kngspook@…

Cc: kngspook@… added

Cc Me!

comment:14 Changed 12 years ago by kngspook@…

Cc: kngspook@… removed

Cc Me!

comment:15 Changed 12 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed

Applied (manually) in r43726. Bitrot factor was moderately high, so keep an eye out for incorrect behaviour. Seems to work basically as intended though.

comment:16 Changed 12 years ago by jmroot (Joshua Root)

Milestone: MacPorts base enhancementsMacPorts 1.8.0

comment:17 Changed 11 years ago by 0xced (Cédric Luthi)

Cc: cedric.luthi@… added

Cc Me!

Note: See TracTickets for help on using tickets.