Scan: Name clashes
sun - May 18, 2009 - 13:47
| Project: | Libraries API |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Libraries |
Jump to:
Description
- #320562-13: Libraries API contains reasoning for not supporting and scanning recursive directories.
- #287321-6: Add wysiwyg_external_plugins module talks about optional add-ons/plugins for a external library, which are equally hosted/distributed externally, but depend on a certain external library. Those plugins can have arbitrary names, such as 'g2image' or 'iespellchecker'. There, we are referring to plugins for a certain editor. However, it's perfectly possible that a completely unrelated external library has the same name.
A conflict crying for a solution.

#1
#2
One possible way to deal with this:
Module A requires library X. But it doesn't necessarily mean that module A uses "X" for the library name. It could be a module option (requested via variable_get() API) with a default value of "X", but the site administrator would be able to change it, from the settings panel of module A, or from the site settings.php script ($conf array), where it is possible to define variables.
Module A could document this in the installation section of its README file, for example.
#3
So today the idea in IRC was to namespace libraries. I.e. instead of putting them directly into sites/all/libraries, we put them into "meta" categories, f.e.
sites/all/libraries/wysiwyg/fckeditor
sites/all/libraries/jquery/ui
sites/all/libraries/jquery/dimensions
etc.
I have to read up earlier considerations in the Libraries API issue/discussion once more to make sure this approach does not open another can of worms.
libraries_get_libraries() would thus not scan sites/all/libraries, but the second level of directories, record the paths, record their name ("ui"), and key them by ... oh my, maybe that was the issue.
#4
Related, possibly duplicate #496240: sites/<site>/libraries: Standard place for thirdparty module requirements
#5
@markus_petrux: If you're in IRC anytime, please join #drupal-wysiwyg, so we can brainstorm and discuss all of this a bit faster.
#6
Tagging.
#7
subscribe
#8
Hmmm, tricky.