drush support for downloading libraries
joachim - August 7, 2009 - 16:04
| Project: | Libraries API |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
It would be awesome if modules that use this API could also have a way of telling Drush the URL of the library to download and where to put it.
So you could do:
$ drush dllib jquery_ui
// download the library files needed by jquery_ui module
#1
FYI, this patch in the
drush_makequeue allows for libraries to be defined in your makefile and retrieved via the download method of choice.http://drupal.org/node/583706#comment-2067524
#2
From what I understand drush_make works to build new sites and not add stuff to existing sites. We need something to add stuff to existing sites as well.
#3
I don't think you need drush make.
Use the same sort of stuff as the drush pm module -- that downloads files from a server, unpacks them, puts them in the right folders.
#4
A couple questions....
Is the libraries api intended to hold the definition of where certain libraries files are to be download from? This would include an index of a lot of libraries? In D7 it will be easier to deal with because of hook_library().
Or, is the intent for the definition to live in the jquery_ui module and the libraries api just has the ability to download it for the jquery_ui module?
Or, both to some degree?
#5
I would suggest it is up to the modules to say where they need things downloading from. More sense from an architecture point of view, and also means the module maintainer can specify the version that matches their code.
I can't find docs on how the API works so I can't make more concrete suggestions...
#6
@joachim - http://api.drupal.org/api/function/hook_library/7
We would need to add a key for the files location which is fine. At the same time, you shouldn't have 2 versions of the same library on a site in most cases. It will just create namespace conflicts and other issues.
#7
@mfer: How. many. times. do. I. need. to. repeat. that. hook_library. is. NOT. the. same. but. a. totally. different. thing?
I also recommended to read up most of the details in the Libraries API issue linked on the project page, which should answer 90% of all questions. Or just look into the queue: #618370: Reasoning Behind Libraries API?
This is one of the remaining major issues that needs to be discussed (elsewhere). We face a N:N relationship here, where neither of both parties can reliably provide standardized library information. So the logical conclusion would seem to additionally allow a N:1:N relationship, which would mean that Libraries API would define a couple of libraries, but installation profiles as well as other modules would still be able to provide their own definitions. However, as soon as there is a 1:N relationship in terms of the library definition, we'll most likely have a problem. This particular question requires to understand the underlying, multi-dimensional challenge, which Libraries API is trying to solve.