Rename drush make file

It's rather a frustrating issue that seems to have been introduced by Drush 5, previously the items referenced in the makefile could be overwritten by the master makefile by ordering them appropriately....

As I prefer the default being that people get the additional modules that add functionality to the module, my solution is that you add a patch to the Custom Formatters line of your makefile to prevent the makefile being inherited into your makefile:

projects[custom_formatters][subdir] = contrib
projects[custom_formatters][version] = 2.2
; Remove Custom Formatters makefile to prevent duplicate downloads - http://drupal.org/node/1721294#comment-6395368
projects[custom_formatters][patch][] = http://drupal.org/files/no_makefile-1721294-1.patch

Oh man, this is a hell of an issue to debug when you don't know what's going on. Originating from a ckeditor issue, the drush maintainers recommend in #drush on irc NOT doing what you're doing:
http://drupal.org/node/1103872

I know you're trying to be helpful, but it's very unintuitive and this bit of magic can be very confusing. In the interest of full disclosive, I just spent like 4 hours debugging this in a large project...

For the record, this is the fix since they don't allow override of recursion on a per-project basis:
http://drupal.org/node/1621030#comment-7072746

I've solved my own problem, so I'm not too invested in what you choose to do, but I'd really recommend rethinking whether this bit a magic is worth it given that can essentially break people's sites if they don't realize what's happening. Cheers!

EDIT: The "concurrency" of drush that is referenced in the link with the solution, simply refers to the fact that drush downloads a few processes at once (in the interest of speed), so in order to properly override, someone needs to know to place the overriding module at least that number of entries ahead (default concurrency is 4, but can vary from command line or drushrc.php file.

Thank you for the patch. This really needs to be fixed as it will immediately break any sites that try to build with drush. I Just spent 3 hours running in circles trying to figure out why older versions of modules were magically being downloaded.

Building a large, complicated distro for a client and it's been so confusing and difficult to find why an ancient version of Libraries module was being downloaded instead of the more recent version specified in our own make files.

The errors this leads to appear utterly unrelated to the issue, meaning people posting in this issue have probably spent hours working out why their builds are broken.

I know it's meant well, but this behaviour by default is just obnoxious.

Makefile removed and details moved to README.txt.

Any chance of getting a release that incorporates the removal of the makefile?

As it stands now, you have to force using the dev version to avoid the kinds of issues with older versions of modules (any reason to specify what version for each module?) and the library giving a DOWNLOAD_ERROR: Unable to download editarea.

Like the above commenters, I went on a multi-hour "learning" exercise until I realized what was happening. I now know a lot more about how Drush Make works, but it was time consuming.

I understand the annoyance, but contrib is generally done for free, and free time isn't something I have alot of. I would love to work on my contrib all day every day, but I can't unless I have clients that pay for me to do so. That does happen, but not often enough.

As for specific version, you should ALWAYS specificy versions of everything in a makefile, not just the modules but also the themes and 3rd party libraries, otherwise what you build today and what you build tomorrow may not match, and if you happen to upgrade one module due to an issue and rebuild from the makefile you may end up with other modules/3rd-party code changing and introducing more issues into the site, which is both dangerous and time consuming.

I will do my best to get a new release out when I can, chances are I should have some time to devote to contrib at Drupalcon.

Sorry to re-open this one and I assume it's just something I'm doing wrong, but....
We have the latest dev of custom_formatters installed in a Panopoly site running on Pantheon.

The Custom Formatters install is complaining that it is not supported, and here are the problems:

Distro Update Manager: ctools version 7.x-1.4+3-dev does not match .make file version 7.x-1.0 from custom_formatters.
Distro Update Manager: token version 7.x-1.5 does not match .make file version 7.x-1.1 from custom_formatters.
Distro Update Manager: libraries version 7.x-2.2 does not match .make file version 7.x-1.0 from custom_formatters.
Distro Update Manager: devel version 7.x-1.5 does not match .make file version 7.x-1.3 from custom_formatters.

Now, I have flushed out the Pantheon repo and rebuilt from my clean local version. There is no make file in evidence. I've tried to run the patch which does nothing because the latest dev already has the patch out.
So: is there something yet wrong in the module or does it have to be a problem with my Pantheon install?

This looks like an issue with 'Distro Update Manager', which I assume is https://www.drupal.org/project/distro_update, as if you have the latest dev version of Custom Formatters it doesn't have a make file and referring to the versions listed above, so it's possible that Distro Update Manager is referencing something other than the local code.

As I've not used said approach I can't confirm.

Ahh, thanks for the clue. I'm not directly using distro manager, but it's coming along with Panopoly.
I wonder how that package has a "leakage" that senses a "problem" in this module? Very odd.
Setting back to closed.