Add drush make file

Just handy if you are building a site using drush make so it will download the tree of dependencies instead of having to specify all the modules and dependencies in the root. I think it could be proposed the drush_make files be generated or maybe drush make changed to make this more automatic, but since you can depend on something like node_reference and that requires references project the .info and .make do not always include the same information.

For instance I download 18+ modules for a site I'm building with only 4 listed in the site profile.

But currently I have to list pathauto's dependency there instead of just pathauto.

#6 was pointed out already, but the issue is that 90% of dependencies tend to be Drupal projects so in the absence of a make file drush make could attempt to use the .info file. Now the issue that will be run into is when building a tree of projects whether or not one down the line has a bad .info file (modules != projects) and if it does do we stop when we may prefer to have it ignored (as it is now) since we are working around it in our own .make file.

Unless someone has a clever way to work around this I don't think it can happen. Having make files in contrib could also replace the current system used by the testbot to download dependencies.

Although the opposite may be true, once the .info file parsing patch that fixes it is committed we may be able to expose the information similar to the update xml and drush could just look there and download the appropriate items.

Not a "bad info file", but one in which the depedencies are not projects. Nothing wrong with that and has to be that way, but doesn't work for drush.

As dmitrig01 said in #7 you can do projects[token] = 1 in the .info file.

That's one hell of an edge-case, but having to have all module developers add this is somewhat annoying although much more standard for compiled projects have specific dependency instructions in their make files and what not.

I mean for the rare case a module does integrate with two module apis (would think their would be two versions of the module for simplicities sake)...then don't add the make entries.

I dunno.

That is simply a wrong usage of dependencies as I have stated more times then I can count. Test modules should not depend on SimpleTest...they are hidden from the interface and the only code that enables them is inside a test (simpletest is not enabled in the testing environment....but is when you depend on it for absolutely no reason)...it is implied...having the dependency causes this problem and the SimpleTest queue to get flooded with non-developers asking how to set it up since they just try to meet all requirements.

You don't see C/C++ projects have a make file with instructions for all the dependencies in a parent project...just not the point of this type of system. It is much more useful when each project contains instructions on how to set itself up.

Recently I have been using it heavily to build out 20+ modules for sites and it is just tedious, hard to manage, and annoying to list dependencies of modules way out in the tree in the root make file. It also doesn't make sense in 99% of situations. Once you manage to wrangle the make file together it is extremely useful and makes it much much easier to setup and update the code.

All the arguments against this have been either ones of duplicity between the .info file and make file, but no one can come up with a clean solution for that since they are not equivalent, edge cases, or symptoms of other misuse.

So perhaps if #102102: Parse project .info files: present module list and dependency information gets committed we will have reliable mapping information on d.o to generate the files if we can find matches...or some-such.

Again these are edge cases....7,637 modules and we have 2 examples in which case they simply don't provide a drush make. Another option is allow drush make to provide a modules argument and it will only build the make files relevant to which modules you want...or maybe a simpler solution would be to have an exclude list of projects. Either way we have 2...count them 2 modules that should not list everything in their drush make.

We are worried about designing for the extreme edge case when drush make doesn't even handle recursive dependencies which is a much more common problem. I think we need to refocus energy here.

If anything it seems people are resistant to this...so for now it will most likely remain an optional thing. All my new modules will have them and people can deal with it as they please.