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 ;)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Title: Libraries API in D8 core. » Libraries API in D8 core?
Category: task » feature
Status: Active » Postponed
klonos’s picture

...#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)?

tstoeckler’s picture

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.)

klonos’s picture

@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?

tstoeckler’s picture

Hmmm...
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.

klonos’s picture

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'

benshell’s picture

+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.

benshell’s picture

Status: Postponed » Needs review
FileSize
2.78 KB

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).

Status: Needs review » Needs work

The last submitted patch, libraries-d8-1167496-8.patch, failed testing.

benshell’s picture

Any idea how to submit a patch for D8 that can pass testing?

klonos’s picture

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.

tstoeckler’s picture

@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.

sun’s picture

@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? :)

tstoeckler’s picture

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. :-)

tstoeckler’s picture

FileSize
28.31 KB

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.

tstoeckler’s picture

Version: 7.x-2.x-dev » 8.x-3.x-dev
Status: Needs work » Active

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.

tstoeckler’s picture

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.

tstoeckler’s picture

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.

klonos’s picture

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?

tstoeckler’s picture

@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.

klonos’s picture

Is this core worthy? If so, should we switch to core queue?

tstoeckler’s picture

Sadly, this won't make it for D8.

klonos’s picture

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.

tstoeckler’s picture

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.

RdeBoer’s picture

Hello,
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.

Rik

gordon’s picture

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.

gordon’s picture

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.

tstoeckler’s picture

Status: Active » Closed (won't fix)

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?!

klonos’s picture

Title: Libraries API in D8 core? » Libraries API in D8 core.
Project: Libraries API » Drupal core
Version: 8.x-3.x-dev » 9.x-dev
Component: Miscellaneous » other
Category: feature » task
Status: Closed (won't fix) » Active

...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.

klonos’s picture

Title: Libraries API in D8 core. » Libraries API in D9 core.

...D9 I said ;)

cweagans’s picture

Title: Libraries API in D9 core. » Libraries API in core

So we don't have to keep updating it :)

klonos’s picture

Yeah, I had a secret hope that it wouldn't get pushed to D10 :P

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Category: Task » Feature request
Issue summary: View changes

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

SKAUGHT’s picture

andypost’s picture

Issue tags: +Needs reroll
SKAUGHT’s picture

SKAUGHT’s picture

Wim Leers’s picture

This is by definition not a contributed project blocker. Because Libraries API is a contributed module. This is merely a feature request to not have it be a contributed module anymore.

Wim Leers’s picture

Component: other » asset library system

This is probably the component that fits best.

SKAUGHT’s picture

Thanks.

My goal is to try to gather attention to the issue as a whole, as there are a variety of other issues that are collecting. As I myself, am simply trying to port a module to 8 and am finding a huge whole in Libraries handling for 8.

As i've looked through other contrib modules that are:

  1. A). including the library directly in their repo (breaking licensing restrictions, bad form). B) and not nice sharable between modules, and themes..
  2. either telling user to install into /libraries or /sites/all/libraries - which don't exist, and is confusing to those who aren't dealing with multisite (which is a majority of sites).
  3. if not then, install into that module folder (to beat point A, but not B.

core certainly should include the Libraries API.

dbjpanda’s picture

Assigned: Unassigned » dbjpanda
dbjpanda’s picture

Hi, I am a newbie here. can you please tell me if the recent patch needs to be rerolled?

Cameron Tod’s picture

Hi dbjpanda - this issue is pretty old now and the patch in #15 was actually against the Libraries module and not against core. I think if you want to work on this one you'll need to write a new patch against core 8.2.x.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Manuel Garcia’s picture

Issue tags: -Needs reroll

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Status: Active » Closed (duplicate)
Related issues: +#2873160: Implement core management of 3rd-party FE libraries

Marking duplicate of #2873160: Implement core management of 3rd-party FE libraries which has much more up-to-date discussion.