This didn't make it in D7 core (#536126: target core inclusion for D7), but now we have a stable release and D8 is open. So, no excuses any more! Right ;)
Same excuses as in #1144992: Backport 7.x-2.x to 6.x-2.x
...#1555888: Libraries API: Stable 2.0 release? is marked as RTBC, but as Tobias said:
...I think it makes sense to give people who are successfully using the current release a stable.
...this stable is more like a release after popular demand rather than one that implements all the API features that were initially planned for 2.x. So, what does this mean for this issue here? Do we wait for 3.0 before considering including this functionality in D8 core? Should we switch this to D8 core queue in order to get some attention (and perhaps some help too)?
Do we wait for 3.0 before considering including this functionality in D8 core?
Yes, definitely. 2.x simply has to many defifiencies to be core worthy. Also for 3.x we're not only trying to tackle a whole new level of both DX and UX, but also we will try align with as many D8 core paradigms as possible. That includes OOP-ifying, PSR-0 style autoloading, and Composer most prominently. So if we were to try to put 2.x in core, it would probably end up something like what we envision for 3.x anyway, just less thought through.
Whether we actually make it for D8 depends on many things. I would like to say yes, but given the amount of time I've been able to invest in Libraries API in the last months (~0) and the fact than sun needs to land more killer patches for CMI and whatnot, instead of dealing with this, I -- sadly -- wouldn't want to get anyone's hopes up.
In theory, having this in 8.0 core, is the plan, though.
Hope that helps. :-)
(Btw, if you post something here, and would like me to answer, please set this to "active" or something, as "postponed" issues don't show up in my queue. I saw this merely by chance.)
@tstoeckler: Hey Tobias! Thanx for even taking the time to reply to this. It's great to hear that the plan is to get this done (even if it finally doesn't happen). If I understand correctly from what you are explaining, the Libraries API that will hopefully be included in core will be a (almost) complete rewrite. If this is true + coupled with the lack of time due to other obligations for you and Daniel is actually the reason why I asked whether we should switch this issue to the core queue. As you say, bringing the module in as is won't happen because its code is not "core-worthy" (I love the awe that these two words bring every time I come across them). So, here's what I thought we should do instead...
1. File an issue in the D8 queue in order to simply get approval on the idea of having the Libraries API functionality (as opposed to bringing the module in as is) implemented in core.
2. If that idea gets approved, convert that issue to a [meta] and list separate issues filed for all the requirements like OOP, PSR-0 style autoloading, etc you mention in your reply.
3. You and Daniel can then jump in as/if/whenever you find some time and either implement these yourselves or guide others to the right direction by reviewing their work.
4. If possible, backport any work done in D8 to a 3.x branch of the libraries module for D6/D7.
...anyways, something like that for a battle plan. I mean, there's only like 6 people following this issue here after I originally filed it a year ago and it'd be a waste not to get some more attention for a module that is installed in 1 out of 3 D7 installations. Right?
I don't think there is anyone in principle against having this in core. So any discussion about this, must be a discussion about the specifics. And in terms of specifics, I would tend to disagree with your proposal to move this in the core queue. A lot of the work that needs to be done, doesn't come with an instruction manual, but rather needs yet to be thouroughly thought out. Since this is complete vaporware at the moment, in the core queue, it would not spark much progress, IMO.
That said, we're not hiding any of the development, and anyone who wishes to contribute, should definitely do so. For now let's leave the discussion here, though.
Fair enough Tobias.
...still -as I already said- the fact that even after a year there's only 7 people following this issue is pretty discouraging. I merely wanted to say that if we don't get more attention, I'm afraid that this won't happen anytime soon. Sure, I'm aware that those working with D8 core and the initiatives already have their hands full, but you surely cannot argue that there's far more people monitoring the core queue than those of Libraries API. That + I still cannot put code where my mouth is so, ...just sayin'
+1 for libraries in D8 core. I just wanted to follow this issue and say I'm interested and possibly available to help if I knew what to do. I'm an experienced developer, and I'm starting to dig into D8 core, but I really don't know much about the Libraries module--just that I use it and need it.
Update: I've successfully updated Libraries 3.x to work with D8. The changes from 7.x-3.x-dev-1704738-tstoeckler were very minor. I'm sure there are lots of issues remaining, but I got the essentials working which I needed to get AmazonS3 working in D8 (I will also be contributing patches for it, and its other dependencies: awssdk and system_stream_wrapper).
The last submitted patch, libraries-d8-1167496-8.patch, failed testing.
Any idea how to submit a patch for D8 that can pass testing?
I *guess* there needs to be a 8.x branch that you need to set the issue version to. Don't know for sure though.
...or you could try setting the issue's project to Drupal core and then setting it to 8.x.
@benshell: Thanks for the patch! I actually decided (yesterday, I think) to code 3.x against Drupal 8, not Drupal 7. I had already made some of the changes, but for example forgotten the cache ones, so *thx* :-)
We don't really have tests in 3.x yet, so that shouldn't be a problem. I don't know when I will get to it, but I will commit the remaining hunks from your patch to my branch. Since this is still in the very (!!!) early stages, I'm hesitant to actually branching a 3.x for now. I'll just work in the feature branch, until we have a few more things worked out.
@tstoeckler: Can you move the new code into a 8.x-3.x branch, create a corresponding dev snapshot release, and enable automated testing for it? :)
Well there's already a 8.x-3.x-dev-1704738-tstoeckler for now as part of #1704738: [meta] Make Libraries classes implementing LibraryInterface. I will pull the basic "porting"/"non-rewrite" stuff out into a 8.x-3.x and enable tests. That is a good idea. That way we'll know directly when things upstream break our code. Then I'll also be able to mark this issue against 8.x-3.x which I just tried to do and failed. :-)
Committed the attached patch to a new 8.x-3.x branch: http://drupalcode.org/project/libraries.git/commit/4c4321a4be79080e5c49a...
Will create a release node now and enable testing. If anything upstream breaks tests, I guess we can open new issues for that now.
Marking against the new version.
For people following along at home, http://drupal.org/project/issues/libraries?version=1775738 is a list of issues against 8.x-3.x.
Also marking "active" as there are no concrete plans for moving Libraries API into core for now.
Oops, I just realized I forgot to remove the now obsolete tests/libraries.test file. I think that is also what currently makes the qa.drupal.org test fail (http://qa.drupal.org/pifr/test/333418). I will move that to a new issue, since this issue is for potentially moving Libraries API into core.
Removing tests/libraries.test seemed to do the trick. The tests now pass (yay!). I opened #1779714: Port to Drupal 8 so that we have a tracking issue in case anything comes up in the future. I'll leave this issue be for now.
The README in 8.x still says:
...external libraries is separate from installing this module and should happen in the sites/all/libraries directory.
Aren't we going for the top-level /libraries directory similar to how D8 contrib has moved to top-level /modules, /themes, /profiles?
@klonos, yes we are. In fact we already did, in libraries_get_path(), but apparently forgot to update the documentation. Thanks for that! I will re-open #1779714: Port to Drupal 8 and post a patch over there.
Is this core worthy? If so, should we switch to core queue?
Sadly, this won't make it for D8.
Yeah, I pretty much realize that, but should we switch this to Drupal core issue queue (and switch to 9.x)? Does it make sense to keep the issue here? That's what I'm asking.
At this point an issue in the core queue doesn't make much sense. That would be the case if there were a clear vision and a way forward to achieve it. That is currently not the case. I don't know if we want to keep this open at all or not.
So this module didn't make it to D8 core.
This is a hugely popular module in D7, a dependency for many contrib modules and therefore holding up D8 contrib development.
What is the status of the port of this module to D8, please?
Can we please have a D8.x snapshot release visible on the project page?
Or is the plan for D8 contrib to have this functionality done through Composer Manager?
Thanks in advance for your reply.
I have spent some time today and have libraries upgraded to D8, and passing all the tests. see #2058371: Upgrade Libraries API to 8.x for the aggresgated patch.
see https://drupal.org/node/1775738 for the latest dev snapshot. It needs #2058371: Upgrade Libraries API to 8.x still but soon I hope that will be commited.
Re #25 I think there is still a use-case for this module on top of Composer Manager. That solves only part of the problem.
I'm going to close this issue. We have #2058371: Upgrade Libraries API to 8.x for the port. Maybe if we can whip up a core-worthy D8 version around the time 8.0 will be released, we can get it early into D9?!
...lets move this to core queue and push to D9. It would be a pity to start a new issue and loose all the comments and history above.
...D9 I said ;)
So we don't have to keep updating it :)
Yeah, I had a secret hope that it wouldn't get pushed to D10 :P
Drupal is a registered trademark of Dries Buytaert.