You have requested a non-existent service "islandora_riprap.islandora_riprap_utils"

[ruebot]

I'm running into this issue trying in install Islandora Riprap in our Playbooks. We're running Drupal 9.3.0-dev, so that might be the cause of the issue based on what I see here.

$ /var/www/html/drupal/vendor/drush/drush/drush --root /var/www/html/drupal/web -y en islandora_riprap

In Container.php line 151:
                                                                                        
  You have requested a non-existent service "islandora_riprap.islandora_riprap_utils".  Did you mean this: "islandora.utils"?

I tried adding an alias to the services.yml and setting up autowire, but neither of those options worked. I thought it also might be a namespace issue, and tried (below diff) throughout the module to no avail as well.

-    $utils = \Drupal::service('islandora_riprap.utils');
+    $utils = \Drupal::service('islandora_riprap.islandora_riprap_utils');

[mjordan]

I have only enabled this module in a standard Islandora Playbook VM (also running Drupal 9.3.0-dev), and can't replicate it:

vagrant@islandora8:~$ /var/www/html/drupal/vendor/drush/drush/drush --root /var/www/html/drupal/web -y en islandora_riprap
 [success] Successfully enabled: islandora_riprap

Mind you, I'm running that manually as the vagrant user, not via an ansible role. Can you not deploy Islandora Riprap via your playbook, but run it manually after the install is complete? If it gets enabled like it does for me, we've narrowed down the problem to being specific to its being enabled via ansible. At least then we'd know where to look to modify the module.

[ruebot]

Ok, good to know you're on 9.3.0-dev. I thought that may have been the underlying problem. Good call on moving enabling it. I'll give that a shot and see what happens.

[ruebot]

Did a fresh build on our playbook, which is largely the Islandora Playbook, and got the same thing 😢

vagrant@islandora8:/var/www/html/drupal/web/modules/contrib$ git clone https://github.com/mjordan/islandora_riprap.git
Cloning into 'islandora_riprap'...
remote: Enumerating objects: 707, done.
remote: Counting objects: 100% (125/125), done.
remote: Compressing objects: 100% (92/92), done.
remote: Total 707 (delta 51), reused 88 (delta 29), pack-reused 582
Receiving objects: 100% (707/707), 661.80 KiB | 4.98 MiB/s, done.
Resolving deltas: 100% (332/332), done.

vagrant@islandora8:/var/www/html/drupal/web/modules/contrib$ /var/www/html/drupal/vendor/drush/drush/drush --root /var/www/html/drupal/web -y en islandora_riprap

In Container.php line 151:
                                                                                                             
  You have requested a non-existent service "islandora_riprap.utils". Did you mean this: "islandora.utils"?  
                                                                                                             

vagrant@islandora8:/var/www/html/drupal/web/modules/contrib$ drush status
 Drupal version   : 9.3.0-dev                                         
 Site URI         : http://default                                    
 DB driver        : mysql                                             
 DB hostname      : 127.0.0.1                                         
 DB port          :                                                   
 DB username      : drupal8                                           
 DB name          : drupal8                                           
 Database         : Connected                                         
 Drupal bootstrap : Successful                                        
 Default theme    : bartik                                            
 Admin theme      : seven                                             
 PHP binary       : /usr/bin/php7.4                                   
 PHP config       : /etc/php/7.4/cli/php.ini                          
 PHP OS           : Linux                                             
 Drush script     : /usr/local/bin/drush                              
 Drush version    : 10.5.0                                            
 Drush temp       : /tmp                                              
 Drush configs    : /var/www/html/drupal/vendor/drush/drush/drush.yml 
 Install profile  : standard                                          
 Drupal root      : /var/www/html/drupal/web                          
 Site path        : sites/default                                     
 Files, Public    : sites/default/files                               
 Files, Temp      : /tmp   

The only think that I can think of is that there might be something off in our yudl8_defaults, which is a modified islandora_defaults. I'll dig into that, and if you have any other ideas, let me know, and I'll dig into those.

[ruebot]

I've added the Riprap playbook to the Islandora Playbook, and I get the same error.

So, I believe I've eliminated the York playbook. Though, it might be our Riprap playbook, but I'm not positive it is the case.

This is my diff on the Islandora playbook if you want to try and reproduce:

[t-cao19]

Was wondering if there's any updates about this? What I've tried so far was following the messaging and replacing the service call with "islandora.utils" and it seemed to work and allowed me to install the module. Then afterwards, I was able to revert the code back. Not quite sure if this is a legit way, seems to be a problem for Drupal 9 as I tried with Drupal 8 and got no errors. Any ideas, thoughts, feedbacks? Also I was curious what's the reason for the Islandora dependency? Thanks!

P.S. I'm a newbie to Drupal, Islandora, etc. So sorry if I'm a bit clueless on all of this.

[mjordan]

@t-cao19 @ruebot no update, but I am wondering if a way around this problem is to combine the IslandoraRiprapUtils service class into the Riprap utils service class. I don't think there is a reason they need to be separate. Want me to do that and push up a branch you can test?

[ruebot]

@mjordan that sounds like a possible solution, and I'd be happy to give that a test.

[mjordan]

Great, thanks. I notice that i did a piss-poor job of removing references to Gemini (#39) so I'm going to clean those up as well.

[mjordan]

OK, the issue-46 branch incorporates both services into one, eliminating "islandora_riprap.utils". Can you see if this version solves the issue?

[t-cao19]

Thanks @mjordan for the update and all your efforts. I just pulled down branch issue-46 and tried installing this version of the islandora-playbook module but unfortunately I get a similar error:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "islandora_riprap.riprap".

I've been trying to look around on the internet to look for a potential fix but so far nothing works.

[ruebot]

I can confirm the same error as @t-cao19 on my end with issue-46.

The only thing that I have found that works, is to delete islandora_riprap.install. I suspect it is because of the check of making sure the service is available before it is installed. I think something changed or was enforced with Drupal 8.9 to 9.3 updates around services and autowiring. I remember this and this bit catching my eye when I was troubleshooting:

Since Symfony 4 (new in Drupal 9) PHP classes are not autoresolved. If your services are autowired, but their injected classes are not, it is better to write your own service provider for your module than maintaining a MODULENAME.services.yml file in your Drupal module.

and

In Drupal 9 some autowiring "magic" from Drupal 8 was removed, so PHP classes around your services are not autoresolved. Drupal also overrides the Symfony dependency injection by its own logic, therefore you must write your own service provider class in your module to autowire your service containers (basically all PHP classes, except e.g. Drupal Plugins or Drupal Entities, which Drupal 9 resolves by its own).

I tried a bunch of stuff on a local branch, and couldn't get anything to work before I disappeared on vacation.

[mjordan]

OK, thanks to both of you for testing. @ruebot I've relocated the hook_requirements to the .module file, and removed the .install file. Care to pull in the changes to issue-46 and test again?

[ruebot]

@mjordan sure thing!

[ruebot]

@mjordan I think we're good to go now! I was able to fire-up machine cleanly with that branch. thank you! 🙏

[mjordan]

Awesome! That took a while to track down. Thanks for finding it, and for the leads as to what could have been the problem. It was pretty esoteric.

@t-cao19 no need for you to test, but if you can that would be great.

[t-cao19]

@mjordan same as @ruebot, all good to go! I've just been busy I forgot to mention but everything seems to be working fine. Big thanks for all your help, life saver 🙏🙏🙏

[mjordan]

Excellent - thanks both! I can't merge at the moment but will do so this evening.

[mjordan]

Resolved with a5d7d50.