I have updated SWF Tools to use libraries, but is there a consensus or place to record names that modules have assumed for a library?

SWF Tools relies on a lot of support libraries for the various players, so as far as possible I tried to use the "root" name of the tar or zip when it is unpacked to make it nice and easy for the end user. There are a couple of exceptions where I have to support multiple versions of a player that might have the same name.

It occurred to me that other modules implementing, for example, the JW Player, might want to know the name I assumed (if I am the first to assign one!) so they can use the same library, and equally if someone already found a home for a library then I can just use that rather me creating a new copy of a library.

Is there some value in a docs page, perhaps organised as a simple list of library "readable" names, and the corresponding library name that the first implementing module assumed?

I'd be happy to kick start a docs page with my SWF Tools list if this is "a good thing to do"

In general terms, libraries works nicely with SWF Tools and solves a support request I had for users wanting to maintain different library versions on different sites!

#2 list_of_libraries.png48.27 KBtstoeckler


Title:Is there a list of names that modules are 'claiming' for libraries?List of registered libraries (directories)
Category:support» task
Priority:Normal» Critical
Issue tags:+Libraries

Very good question. :)

irakli just recently added the first documentation page: http://drupal.org/node/735160

Though I'm not sure whether this is the proper way to move forward. #719896: Add a hook_libraries_info() contains some additional considerations around this topic -- namely, whether Libraries API itself (or a separate project with plenty of co-maintainers?) shouldn't register libraries that are used by more than one module.

Furthermore, the more modules are using Libraries API, the sooner we will have to deal with #465908: Scan: Name clashes

new48.27 KB

Now that #719896: Add a hook_libraries_info() is in, I think we should have a documentation page, which is basically a table listing all known implemented libraries. Whether Libraries API ends up implementing some libraries itself or not should not hold that up. What I imagine is basically something like the attached screenshot (done with Firebug). I would have actually created it already, but I'm not on the Docs team, so can't add < table > 's. Thoughts?

While a documentation page like I proposed in #2 wouldn't be inherently bad, I think, we need something which is easier to access for the ordinary module developer.
1. Only people on the docs team can write < table > 's.
2. Editing a table that could get potentially huge is a pain.

I put together a little install profile, which sets up a node type ('library'), which lets you enter a name and the latest (supported) version of a library, and then lets you upload a libraries.info file. It's not really finished yet, but I do like the direction.
The code is here: http://drupal.org/sandbox/tstoeckler/1194784
and you can check it out live here: http://libraries.euve23100.vserver.de/

I'd love to hear your thoughts.
@sun: Just in case you have some time to spare :), you of course have commit rights.

wow, nicey! And clever! :)

Unfortunately, one issue with that: Not all libraries are defined in .info files. Many are defined in PHP :-/

Otherwise, this looks like a nice idea. Let's think about it some more.

Just an architectural note: While install profiles are treated like modules now, it isn't really safe (yet) to rely on them being 100% treated like modules. The profile should contain the actual module functionality in a separate module in a sub-directory of the profile.


I'm in the middle of developing a large module (for doing Electronic Thesis and Dissertations), which is dependent on four or five external javascript libraries (including, for example, json-js). I'm planning on using the Libraries module to support this, but I want to make sure that the names and other info I've got associated with the libraries are set up in a way that makes sense.

json-js, as mentioned above, doesn't have version numbers, but it does have a date embedded in the code. I've been using that as the version number, but perhaps that's not the right approach.

In my opinion, what's needed is a sort of mini drupal.org, but only for library definitions. Each library has a maintainer, or couple of maintainers, who are not necessarily the authors of the library. The maintainers are responsible for keeping a canonical .info file, which developers can use when they want to interact with the library, by transforming the .info file into php code for hook_libraries_info().

This platform could even host a 'drupalfied' version of the library with a .info file attached. The maintainers would be responsible for keeping it up to date, just like a Debian package manager, for example.

I realize that I am proposing a massive amount of infrastructure, but I'd like to get this discussion started again. Even a list on a wiki somewhere would be an improvement over the current shooting in the dark.

Version:6.x-1.0-alpha1» 7.x-2.x-dev
Issue tags:+libraries-7.x-3.x

Re-purposing this issue, due to latest discussions.

The plan is to have a libraries.drupal.org (or equivalent) which acts as a central repository for libraries. Libraries API would then interface with that site to automatically download library information (what is currently library info files (in 2.x)), and then use that library information to automatically download the library.

I will write a proper issue summary soon.

We have not tagged a 7.x-3.x yet, so for now I am simply tagging this. @sun, if you can think of a cooler tag, feel free. :-)

Note that this is intentionally still "critical", this is a central piece of the envisioned 7.x-3.x Libraries API.

Title:List of registered libraries (directories)[meta] Provide a central repository of library information (i.e. libraries.drupal.org)
Component:Documentation» Code

Forgot the reason, I initially wanted to comment: Update the issue title to match the new proposal.

Also, something I just thought of: http://drupal.org/sandbox/tstoeckler/1194784
This is quite some time ago, but I cooked a really small install profile that provides such a library repository. Note that the in light of the new proposal, the code is almost certainly completely obsolete. I'm mentioning this only for reference.

Also, I had no idea what "Component" this is, but "Documentation" felt wrong.

Version:7.x-2.x-dev» 7.x-3.x-dev
Issue tags:-Libraries, -libraries-7.x-3.x

Tagging with the new version and removing unused/superfluous tags.

Version:7.x-3.x-dev» 8.x-3.x-dev

Changing version to 8.x-3.x

I have packaged the Libraries API for Debian and Ubuntu

This means that library dependencies can be fulfilled by packages in Debian or Ubuntu systems, the details are explained here:


I'd be interested in understanding how this can be co-ordinated with the libraries.drupal.org effort, if that progresses. It would be helpful to avoid duplication of effort, the Debian pkg-javascript team already does a great job of locating genuinely free GPL compatible libraries and packaging them for distribution.

Sadly, the progress on this has basically halted for the last months. So not a great risk of duplication :-/