Download & Extend

Error: Call to undefined function drush_make_libraries() in

Project:Drush Make
Version:6.x-3.x-dev
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

Comments

#1

I had the same problem. The function does not exist. It is being called from drush_make_project.inc, line 246 in the latest HEAD.

To fix, I added a destination:

libraries[ckeditor][destination] = "libraries/ckeditor"

#2

Priority:normal» major

This is happening when you use a stub to just trigger the profile's make file. If I use the same profile's make file with the stub, it works as expected. I think the priority of this bug should be increased.

My build fails with:

ckeditor downloaded from http://download.cksource.com/CKEditor/CKEditor/CKEditor%203.5.2/ckeditor....                                          [ok]

Fatal error: Call to undefined function drush_make_libraries() in /Users/me/.drush/drush_make/drush_make.project.inc on line 246
Drush command terminated abnormally due to an unrecoverable error.                                                                                       [error]
Error: Call to undefined function drush_make_libraries() in /Users/me/.drush/drush_make/drush_make.project.inc, line 246

doing a git grep on the tag before the current shows that function used to exist :)
~/Documents/workspace/drush_make$ git grep -n drush_make_libraries 6.x-2.2
6.x-2.2:drush_make.drush.inc:115:    drush_make_libraries(drush_get_option('contrib-destination', 'sites/all'), $info, $build_path);
6.x-2.2:drush_make.drush.inc:241:function drush_make_libraries($contrib_destination, $info, $build_path) {
6.x-2.2:drush_make.project.inc:246:    drush_make_libraries(trim($build_path, '/'), $info, $this->build_path);

#3

+1, same problem here with the remotes/origin/6.x-3.x branch.

#4

+1
I ran into this when I tried to deploy aegir.make with drush_make 3.x instead of the advised 2.2. Reverting to 2.2 solved my case.

I also found a duplicate report in #1120430: Fatal error: Call to undefined function drush_make_libraries

#5

The function was removed in this commit :

commit 66bdbafc898d99102c85c39ae2f993bb187f2c9d
Author: Dmitri Gaskin <dmitrig01@gmail.com>
Date:   Fri Mar 11 21:57:56 2011 -0600

    Put everything in the projects array

Adding it to drush_make.drush.inc worked for me.

<?php
function drush_make_libraries($contrib_destination, $info) {
  if (empty(
$info['libraries'])) {
   return;
  }
 
$ignore_checksums = drush_get_option('ignore-checksums');
  foreach (
$info['libraries'] as $key => $library) {
    if (!
is_string($key) || !is_array($library)) {
     
// TODO Print a prettier message
     
continue;
    }
   
// Merge the known data onto the library info.
   
$library += array(
     
'name'                => $key,
     
'core'                => $info['core'],
     
'build_path'          => $build_path,
     
'contrib_destination' => $contrib_destination,
     
'subdir'              => '',
     
'directory_name'      => $key,
    );
    if (
$ignore_checksums) {
      unset(
$library['download']['md5']);
    }
   
$class = new DrushMakeProject_Library($library);
   
$class->make();
  }
}
?>

#6

Thanks! Adding the function worked for me.

#7

Just came across this while writing a patch to enhance windows compatibility.
To me it looks like the function and all it's calls can be remove without any impact. All the stuff is handler in drush_make_projects() - at least in the latest version.

#8

Status:active» needs review

I think we can just remove the function call as the commit above states "Put everything in the projects array".

AttachmentSize
0001-remove-depreciated-drush_make_libraries()-function.patch 701 bytes

#9

Also a warning for other, that recent change means you can no longer have a module and library with the same name.

e.g. the follow wont work

modules[jquery_ui][version] = 1.4

libraries[jquery_ui][download][type] = get
libraries[jquery_ui][download][url] = http://jquery-ui.googlecode.com/files/jquery.ui-1.6.zip
libraries[jquery_ui][directory_name] = jquery.ui
libraries[jquery_ui][destination] = modules/contrib/jquery_ui/

you need to make the library a different name, like:

modules[jquery_ui][version] = 1.4

libraries[jquery.ui][download][type] = get
libraries[jquery.ui][download][url] = http://jquery-ui.googlecode.com/files/jquery.ui-1.6.zip
libraries[jquery.ui][directory_name] = jquery.ui
libraries[jquery.ui][destination] = modules/contrib/jquery_ui/

#10

Status:needs review» reviewed & tested by the community

Tested the patch from @univate and it works as advertised. It is needed to make this work too - http://davehall.com.au/blog/dave/2011/05/17/drush-make-and-module-depend...

#11

#8 works here too. Thx univate

#12

#8 is working for me too. Thanks.

#13

I think that this conflicts when downloading projects that include in their makefile their own libraries with the same name, let's say: ckeditor.

I have to try it btw.

#15

Sadly, the decision to take out the libraries code is going to require various projects to modify their previously functioning makefiles. :-/ If it were an option, my vote would go for keeping the function (mentioned in #5) around, because, while probably technically the same as a project, I see value in being able to distinguish between a project and an external library; its all too common that a Drupal module has the same name as the external library it depends on, requiring the workaround mentioned in #9.

In my case, was installing the pft profile. Patch in #8 worked after also editing the make file to change libraries[jquery_ui] to libraries[jquery.ui], as mentioned in #10. Thanks for the tip @univate.

#16

I disagree, the idea to combine everything under a single entity makes sense as what you do to a module you often want to be able to do to a library (e.g patches), so parsing them through the same system I think should make the drush_make code base more maintainable.

But a simple solution could be to prepend something like "projects_" or "libraries_" when parsing the make file so that they continue to have distinct names.

#17

#8 worked for me too, I just notice that the class DrushMakeProject_Library is not used anymore at all, so maybe this can go away as well.

Thanks,
Antonio

#18

Status:reviewed & tested by the community» needs work

Since we have now a bunch of unused code, can we get a new patch that will cleanup that stuff? I am also hesitant in committing something that would break backward compatibility, not sure what dmitri has in mind for compatibility between 2.x and 3.x...

#19

Status:needs work» reviewed & tested by the community

Sorry, my bad, the comment in #17 about the unused DrushMakeProject_Library is actually not true.

The class name is built dynamically from the project type:

drush_make.drush.inc:218:      $class_name = 'DrushMakeProject_' . $project['type'];

a simple grep didn't find any reference but it didn't mean it was not used.

I'll be more careful the next time, setting back RTBC in the hope the patch can be merged soon.

Thanks,
Antonio

#20

sub

#21

@univate from #16, the new behavior for project and libraries naming is something that should really be addressed, this is the related issue #1164608: libraries are overriding modules.

I am cross linking on the two issues so that there could be a more effective communication.

Thanks,
Antonio

#22

Ping.

The patch from #8 is OK IMHO.

Thanks,
Antonio

#23

Status:reviewed & tested by the community» fixed

merged in 3.x, not 2.x since the function still exists there...

#24

@anarcat, has the commit been pushed already? I cannot see it in the history, and the patch still applies to the latest 3.x.

#25

Status:fixed» reviewed & tested by the community

Re-opening since it doesn't look like the fix was pushed.

#26

I'm getting this issue with latest 3.x dev code.

#27

Priority:major» critical

Confirming that this is not in the latest, bleeding-edge 6.x-3.x code, and also confirming fix.

Bumping to critical.

#28

Status:reviewed & tested by the community» needs review

The patch doesn't seem to apply anymore... Any thoughts on this?

AttachmentSize
arrayitupyo.patch 542 bytes

#29

@Rob Loach: It seems like you uploaded the wrong patch to this issue.

Chances are though that 3.x will never see a release, #1310130: Put drush make in drush core

#30

Status:needs review» closed (won't fix)

[ 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.

nobody click here