For #542940: [meta] Support for downloading libraries via Composer and related issues we decided that we'll only support automated downloads for libraries for which the vendor provides a "latest stable" release download URL; e.g.

http://example.com/mylibrary/stable.tar.gz

In essence, Libraries API behaves exactly in the way it was designed for: Determine the actual version, decide whether that's supported, and if so proceed with loading/integration.

However, I could easily foresee cases in which a library's latest stable is compatible with, say, D7 only, but not D6. Easiest examples are probably PHP libraries; e.g., the latest stable might have been revamped/rewritten for PHP 5.3 (D8 only), and D7 and below need to grab an earlier version - or alternative latest stable download URL for PHP <5.3.

Thoughts, feedback, drinks?

Comments

RobLoach’s picture

RobLoach
he/him
CreditAttribution: RobLoach commented

Maybe providing "download" support for "versions" or "variants"? In the end though, it should be up to the module maintainer to define how automated downloading is handled.

  // By default, get the latest in the 4.x branch.
  $libraries['tinymce']['download']['url'] = 'http://tinymce.com/tinymce-4.3.tar.gz';

  // Provide support for the 3.x branch though.
  $libraries['tinymce']['versions']['3.8']['download']['url'] = 'http://tinymce.com/tinymce-3.8.tar.gz';

Override which version is downloaded via:

  drush libraries-make tinymce --version 3.8

... Something along those lines?

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler as a volunteer commented
Title: Introduce core compatibility for latest stable download URLs » Allow library dependencies to be versioned
Version: 7.x-2.x-dev » 8.x-3.x-dev
Issue summary: View changes

Re-targeting this for 8.x-3.x. We now have the ability of modules to declare a dependency on a library, but that dependency cannot be versioned. We definitely need to support that.

rjacobs’s picture

rjacobs CreditAttribution: rjacobs commented

Just curious, could this be rolled-into #2774313: Validate library dependencies when extensions are installed and more gracefully deal with library-specific errors at runtime or is it an isolated task?

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler as a volunteer commented

Good question. I have not actually spec-ed out #2774313: Validate library dependencies when extensions are installed and more gracefully deal with library-specific errors at runtime in my head, so I really can't say. If it ends up being easy to implement versioning there, that would be awesome and then we can just close this. We should definitely keep this in mind over there, in any case. But for now I think it makes sense to leave this open to make sure we don't forget about this.