libraries are overriding modules

I am seeing the same issue using Drush 4.3-dev and Drush Make 2.0-dev that came installed with the Drupal Quickstart VM.

Not sure why the library would override the module, but seems odd to me.

I just upgraded to the latest Drupal Quickstart which is using Drush 4.4 and Drush Make 2.2.

I no longer see this issue. So maybe in Drush Make 3.x-dev there is some kind of regression bug.

I am also having this issue:

core = 7.x
api = 2
projects[] = "drupal"

projects[getid3][type] = "module"
projects[getid3][version] = "1.x-dev"
projects[getid3][subdir] = "contrib"

libraries[getid3][download][type] = "get"
libraries[getid3][download][url] = "http://downloads.sourceforge.net/project/getid3/getID3%28%29%201.x/1.7.9/getid3-1.7.9.zip"
libraries[getid3][directory_name] = "getid3"

Rolling back to 6.x-2.x branch solves the problem.

sub

IIUC this is due to commit 66bdbaf (Put everything in the projects array) as pointed out in #1091510: Error: Call to undefined function drush_make_libraries() in.

The attached patch tries to fix the behavior. I checked the other uses of $info['projects'], and there should be no side effect with this change, but a review is always needed.

If the change is OK (code and comment), the patch can be applied with git am in order to preserve the authorship, and the long commit message which explains the issue.

Thanks,
Antonio

The previous patch was not considering that directory_name can be assigned from the project name, the attached one overcomes this, but I now consider the patch just a workaround. A cleaner way to index projects with the same name but different type needs to be found, but I haven't got much time to spend on this.

Regards,
Antonio

If projects and libraries are treated the same way, then IMHO libraries[] must be deprecated altogether (ie ignored) so that people are forced to rewrite their scripts to follow a convention that inherently avoids the namespacing issue first metioned in comment #9 on #1091510-9: Error: Call to undefined function drush_make_libraries() in.

With libraries[] deprecated, the example from #4 might be rewritten like this, to avoid the namespace issue...

core = 7.x
api = 2
projects[] = drupal

projects[getid3][type] = module
projects[getid3][version] = 1.x-dev
projects[getid3][subdir] = contrib

projects[getid3_lib][type] = library
projects[getid3_lib][download][type] = get
projects[getid3_lib][download][url] = http://downloads.sourceforge.net/project/getid3/getID3%28%29%201.x/1.7.9/getid3-1.7.9.zip
projects[getid3_lib][directory_name] = getid3

The idea was that either one can be used: using libraries is a shortcut for [type] = library.

@jwilson3: the idea is the one about inheritance from Object Oriented programming: a library IS A project of course, but it makes sense to have a name for it because it is a particular type of project, a possible definition in this context could be: "a library is a project which is placed under a libraries/ directory".

As you know the problem here is that different projects with the same name but different type are not handled correctly right now, your trick would work but generally a library can even be a drupal.org project, so I'd like that we keep putting "actual names" in the first square brackets.

@dmitrig01 : AFAICS the regression we are facing is because drush_make indexes the projects using the name (the string in the first square brackets), I think that the 'name' and the 'key' should be distinct concepts, I am still not fully at my ease with drush_make codebase but I am looking into that.

Thanks,
Antonio

This is what I have in mind, see the attached patch which tries to make a clearer difference between a key used to index projects in the array and the project name. While at it I tried to use better names for the keys, $key can be misleading sometimes when there are nested loops.

Patch is git am ready, in case you find it valid already.

Regards,
Antonio

I think the discussion of this issue should be merged with #1091510: Error: Call to undefined function drush_make_libraries() in

[ Powered by #1115636: Issue Macros and Templates - Drush Make]

Drush make is being merged into drush core (discussed in issue:#1310130: Put drush make in drush core)
This means that the issue queue is also moving. The Drush project has a component called 'Make' for this purpose.

We would like to take this opportunity to leave behind old/obsolete issues, allowing us to focus on a stable make command in core. E.g. one of the major tasks ahead is making more use of the Drush core code for handling downloads and decompression.

If you feel that this issue is still relevant, feel free to re-open and move it to the Drush queue.

More information will be posted on the drush_make and drush project pages.