I'd like to use service_container together with xautoload. The autoloader requirement for service_container in the module description states:

registry_autoload or any other PSR-4 autoloader.

But service_container.info explicitly requires registry_autoload! If nothing else, this is a documentation error.

Do people use service_container with xautoload? If so, how? I can think of two solutions:

  1. Patch the info file :/
  2. Create a phony registry_autoload module

Both solutions are not ideal.

I've marked this issue as a feature request because I think it would be useful if the autoloader dependency was "soft" (i.e. not listed as a depencency in the info file) so users can choose what autoloading library to use.

Another approach would be to use a meta-package scheme where service_container requires registry_autoload and a service_container_core module. Users who want to use xautoload can then simply depend on the core package only.

CommentFileSizeAuthor
#7 2608500-6.patch2.23 KBmarkhalliwell

Comments

jsst created an issue. See original summary.

fabianx’s picture

I agree, I think the best is to create a new project any_autoloader, which supports registry_autoload, composer autoload, xautoload and autoloader and provides a bridge between them.

jose reyero’s picture

As it seems in 2 years no one has created that 'any_autoloader' -which is a good idea, only it takes some work...- could we just remove that 'registry_autoload' dependency from the info file, let it only in the documentation?

pol’s picture

Hi,

I've got no more news from FabianX since a couple of months...and I don't know if this project is still maintained.

Fabian, if you read this, it would be great to have a bit of help to update it...

markhalliwell’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Assigned: Unassigned » markhalliwell
Issue tags: -xautoload registry_autoload

I've gone ahead and created https://www.drupal.org/project/any

It's a simple and abstract module, so it's not specifically tied to autoloaders.

I'll commit a patch to the new 7.x-2.x branch shortly.

  • markcarver committed c565310 on 7.x-2.x
    Issue #2608500 by jsst, markcarver: Allow usage of alternative...
markhalliwell’s picture

Assigned: markhalliwell » Unassigned
Status: Active » Fixed
StatusFileSize
new2.23 KB
fabianx’s picture

+1 to the approach - nice work!

markhalliwell’s picture

Project: Service Container » Backport
Version: 7.x-2.x-dev » 7.x-4.x-dev

The 7.x-2.x branch was premature, this project has been deprecated in favor of https://www.drupal.org/project/backport.

This has been committed to the 7.x-4.x branch there.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.