Parsing .info files for dependencies

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
catch's picture

Idea came up on this issue (twice) http://drupal.org/node/265450

This information would be useful for a couple of reasons:

Showing dependencies automatically on project pages - some maintainers are kind enough to list them in the description, but what's in the .info file is the best bet.

Showing related modules - modules like token, views, voting API could show dependent modules, modules with dependencies could show other modules with the same dependencies (cck, jQuery UI).

I guess we've already got code which determines what the dependencies are (although I've never looked at it) so showing dependencies on a project page might not be the hardest thing in the world, using it for recommendations would of course be a bit trickier. Does this sound like something that'd be workable? Should it be a feature request against project* if so?

Comments

Probably not for project*

aclight's picture

I don't think this request would be best to make against the project module, since .info files are a drupal thing. IMO, it's better to make the request against the drupal.org module.

I agree. Probably best to

ixlr8's picture

I agree. Probably best to make the request there, but I do think it's a really good idea.

Mike

Parse during packaging script

dww's picture

If we were going to do this, I'd say the right time is during the packaging script. It's already gotta check out the source, and it's already appending goo to the .info files. It wouldn't be that hard to parse the .info files at the same time, and store the results in a DB table somewhere. However, the schema for the new DB tables is going to be pretty tricky, since you're entering into the land of single releases of a project which include multiple modules, and each module has its own .info file...

http://drupal.org/node/263994 is another example where this sort of data might be useful.

All that said, this is pretty low on my priority list, so someone else is going to have to carry the torch on this one. ;)

Cheers,
-Derek

Module dependencies

lucyconnuk's picture

Hi, I'm new to this group, so please excuse me if I'm posting in the wrong place or talking nonsense.

Is there any way to parse all the module .info files, in order to produce statistics on which modules are most depended on (perhaps even a tree view of dependants?)

I'm thinking that modules which have more dependants are going to be more "important" than others, and that information might be quite useful when choosing a module (e.g. choosing which family of image modules to use).

Lucy

not yet

catch's picture

If this gets implemented, this would be one thing we could do with it (and it'd be an interesting statistic to have) - however this discussion is as far as it's gone for now.

not sure how useful this is, but...

greggles's picture

You caught my interest ;)

I did a checkout of all contributed modules tagged with DRUPAL-6--1 and ran this command on them

find ./ -name '*.info' -exec grep ^depend {} \; | gawk '{print $3}' | uniq -c | sort -n

That
1. finds all .info files,
2. searches through them for a line that begins with "depend" (some files had "; depend..." which is commented out so I wanted to remove those from the sample
3. prints out the 3rd item on the line when split apart by whitespace (which is the name of the module after the = sign)
4. Creates a unique list with the count of number of occurrences preceding the module name
5. Sorts them numerically

and...

the data is pretty useless ;)

      4 taxonomy_image
      4 views
      5 emfield
      5 mapi
      6 spaces
      7 activity
      7 bot
      7 messaging
      8 ad
     10 swftools

A more useful (but difficult to do) weighting might be based on a weighting of some measure of module importance like number of downloads or number of installed sites or, like you say, also taking into account second level dependencies.

--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book

modules are not depending on

moshe weitzman's picture

modules are not depending on views or og or votingapi? i find that hard to believe. and surely many depend on good ole token.

Minor issue with used command

SloMo's picture

There's an issue with your command that leads to these misleading results. The main ingredient, that is missing, is a 'sort' between 'gawk' and 'uniq' because 'uniq' performs no sorting on its own but merely joins consecutive identical lines. Apart from this there are also issues with depend-lines not exactly matching the implications contained in this command (probably only very few).

After running

find . -name '*.info' -exec grep '^depend' {} \; | gawk '{print $3}' | sort | uniq -c | sort -n

I get a more realistic
...snip...
10 mapi
10 profile
10 upload
11 ad
11 swftools
12 image
12 storm
13 comment
13 menu
18 services
21 search
29 views
47 content
54 taxonomy

great - thanks!

greggles's picture

Perfect - this makes a lot of sense. Thanks for the fix and the explanation.

That is great

lucyconnuk's picture

That is great - Thanks Greggles and SloMo. I think it's useful because if a module developer has their module depend on another module, it shows they trust that module - and a module developer's opinion is probably more useful than most people's.

Lucy

What the statistics is

earnie@drupal.org's picture

What the statistics is liable to show is that a particular module should be included with Drupal core. It shows how important the module is to a major release of Drupal.

This is a great suggestion,

sdboyer's picture

This is a great suggestion, but I think will probably end up following on the tail of some larger innovations. Module dependency handling is a problem drupal has in general, not just on project pages. If you've ever tried to enable modules with some nested dependencies, you'll have experienced this firsthand.

The drush module manager module takes some great steps towards good dependency calculation, but it needs more visibility, and potentially integration into core (at least the dependency handling part) before this all could work out, I suspect.

Original issue on d.o about this

dww's picture

BTW, since another duplicate about this just got posted, and I found the earliest issue where we discussed it, I figured I should post here in case others come looking from here. ;)

#102102: Project Dependancies, Subproject, and Library Support

I should take my own advice

catch's picture

I should take my own advice and search the issue queue first before posting ideas like this ;)