Remove Dependencies (Symfony & Drupal Components) from the repository

Unfortunately I won't go the composer only route, because I don't like to force people to use composer. I am okay to use it for tests for now.

I also think the composer autoloader is very "greedy".

On the other hand what I don't get is why you get PHP errors, autoloaders should not load a class twice when it already exists - regardless how often it exists in the code base.

Could you give more information?

What I can offer is three possibilities (as I knew the day was coming someone to ask this):

a) Use sites/all/libraries/[drupal-8/symfony]* with a manual download and a drush make (like other modules, e.g. color module download their JS dependencies).

Unfortunately we had to hack some Drupal 8 core files, so we need to take care of that first. On the other hand, I guess you don't run a subtree split of Drupal 8 core, but probably only components and Symfony.

b) We could re-organize things again and move all libraries to dedicated library modules, one per component:

modules/libraries/drupal/service_container_drupal_core
modules/libraries/drupal/service_container_drupal_component
modules/libraries/symfony/service_container_symfony
modules/libraries/doctrine/service_container_doctrine

+

Using service_container_external_libraries having dependencies on all those.

Making the service_container_external_libraries its own module and having only modules/libraries/drupal/service_container_drupal_core_hacks with a higher weight in service_container itself, we could also avoid the problem of being stable, but still subject to dedicated Drupal 8 / Symfony security issues - just because they are in the code base.

Annotated plugin discovery and Symfony yaml detection would then move back to the main module, which I like.

c) Using hook_system_info_alter() (or what its called) and the dedicated relative path feature in registty_autoload would allow anyone to just alter out the libraries they don't like via simple unset.

On added problematic is that we still want to support PHP 5.3 for various legacy reasons, so we have to hack some components for that, but I think that is fine to skip for anyone not wanting that.

--

I think I tend to a combination of b) and c). I am still not yet sure if I want to make service_container_external_libraries a required module via hook_system_library_alter() or add a hook_requirements() to the installation.

Thoughts?

EDIT:

service_container already has a composer.json so it works for dedicated unit testing - maybe that is conflicting with composer_manager?

Still thinking ...

Yeah, we will do a service_container_libraries module on GitHub and use some magic to avoid it being used as a dependency.

That sounds good. Thanks for your thoughts.

Hi, this is Gisle from the LWG here. I will not deal with technical issues (the dependencies generating PHP errors), but to to clarify things regarding the Drupal.org Git Repo policy.

This project has two 3rd party MIT licensed libraries in the repository: DependencyInjection and HttpFoundation. Third party code is not generally allowed on Drupal.org and must be deleted from the project's repository.

These particular files are made available under the MIT license. This is a permissive license deemed to be compatible with GPL V2+ (the license we require), but an exception to host third party code must be explicitly approved by the LWG. The conditions for granting an exception is described in: 3rd party libraries and content on Drupal.org. However, in this case, no exception has been requested.

For PHP code, the preferred mechanism for adding 3rd party dependencies without directly including the code in the Drupal.org repo is referencing the package via a composer.json file. Alternatively, you may suggest to users procedures for a two phase install that makes use of the Libraries API module for adding 3rd party dependencies.

Please note:

This policy is described in the 3rd party libraries and content on Drupal.org. It also appears in the Drupal Git Repository Usage policy you agreed to when you signed up for Git access, which you may want to re-read, to be sure you're not violating other terms.

The Drupal Association has given the Licensing Working Group the authority to finally deal with issues like this. #2513630: Service Container module includes MIT licesnsed libraries is the related issue in the LWG queue.

If the maintainers of the project do not resolve this issue the project will likely be unpublished and a notice will be posted to the project page.

More importantly, the maintainers who violates the Drupal Git Repository Usage Policy risk losing their git privileges.

Yes, we'll deal with it.

Pol is gonna take care of moving all things over to GH.

Sites then can choose to download the module from GH or use composer + composer manager.

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

Marking as "Closed (won't fix)" because this project is severely outdated and should no longer be used anyway. There is no point in trying to "fix" it.