composer

RuntimeException: Could not delete docroot/core/.git/ ...

First sign of something going wrong, you do a composer update and get this in the middle:
 
  [RuntimeException]

  Could not delete docroot/core/.git/hooks/applypatch-msg.sample:
You can get different messages, core path, whatever. Important to notice is that the process (composer) has been suddenly interrupted. Worst thing is that, after this, you just get:
  [RuntimeException]

  Source directory docroot/core has unpushed changes on the current branch:

  Branch master could not be found on the origin remote and appears to be unpushed
after you try any composer update or install, so you are blocked.
[email protected]:/var/www/vecfullmig$ rm -rf docroot/core/.git/

rm: cannot remove /docroot/core/.git/info/exclude Permission denied

...

Solution is simple, just check what you have in that folder (docroot/core). Its just generated code via composer, so you are good to remove it:
[email protected]:/var/www/vecfullmig$ exit

logout

Connection to 127.0.0.1 closed.

[email protected]:~/projects/personal/vec/vecd8-fullmigration/vecfullmig$ rm -rf docroot/core/

[email protected]:~/projects/personal/vec/vecd8-fullmigration/vecfullmig$ composer update

    1/2:    http://packagist.org/p/provider-latest$d62e317bf7d5968846ee2c0b922c14df60b0c1ca3ae7f714b5e2cb0a1afd1ace.json

    2/2:    http://packagist.org/p/provider-2018-04$f7d80ec02ae656c3d18ff3dedb552ff63a2f728f4ec718d15443f45741f8ab23.json

    Finished: success: 2, skipped: 0, failure: 0, total: 2

Gathering patches for root package.

Removing package drupal/entity_browser so that it can be re-installed and re-patched.

  - Removing drupal/entity_browser (2.0.0-alpha2)

Deleting docroot/modules/contrib/entity_browser - deleted

Removing package drupal/entity_embed so that it can be re-installed and re-patched.

  - Removing drupal/entity_embed (1.0.0-beta2)

Deleting docroot/modules/contrib/entity_embed - deleted

Removing package drupal/media_entity_instagram so that it can be re-installed and re-patched.

But it's still resisting itself. Leave the vm, remove it from the host and all good to continue:

[email protected]:/var/www/vecfullmig$ exit

logout

Connection to 127.0.0.1 closed.

[email protected]:~/projects/personal/vec/vecd8-fullmigration/vecfullmig$ rm -rf docroot/core/

[email protected]:~/projects/personal/vec/vecd8-fullmigration/vecfullmig$ composer update

    1/2:    http://packagist.org/p/provider-latest$d62e317bf7d5968846ee2c0b922c14df60b0c1ca3ae7f714b5e2cb0a1afd1ace.json

    2/2:    http://packagist.org/p/provider-2018-04$f7d80ec02ae656c3d18ff3dedb552ff63a2f728f4ec718d15443f45741f8ab23.json

    Finished: success: 2, skipped: 0, failure: 0, total: 2

Gathering patches for root package.

Removing package drupal/entity_browser so that it can be re-installed and re-patched.

  - Removing drupal/entity_browser (2.0.0-alpha2)

Deleting docroot/modules/contrib/entity_browser - deleted

Removing package drupal/entity_embed so that it can be re-installed and re-patched.

  - Removing drupal/entity_embed (1.0.0-beta2)

Deleting docroot/modules/contrib/entity_embed - deleted

Removing package drupal/media_entity_instagram so that it can be re-installed and re-patched.

Happy days :-)

categorias: 

Howto use Lazy Loading in Symfony2 (and Drupal 7 / 8)

Lazy Loading is a software design pattern which basically allows our classes and objects to be a lot lighter. Faster code, faster applications, less memory used in runtime. The great Martin Fowler says about Lazy Loading:

An object that doesn't contain all of the data you need but knows how to get it.

http://martinfowler.com/eaaCatalog/lazyLoad.html

The key is that your "real" objects are not going to be instantiated unless they are going to be used. How that can be achieved? Easy, with what it is called a Virtual Proxy. As in every project, you can always code your own implementation, but the key about design patterns and software engineering is to reuse as much as possible. And regarding Lazy Loading, Symfony 2 has a nice implementation called Proxy Manager Bridge, which does exactly that in Symfony 2.

Recently we discovered that our implementation of Lazy Loading was not working properly in Drupal 7. We were using a custom module which we created in Capgemini, Drupal Symfony Inject, to inject our own implementations of Symfony 2 classes in Drupal. The module works great, but for some reason the Lazy Loading was not working, the objects were always having the real implementation of the object itself instead of the proxy (for more info, check the documentation in Symfony 2 about Lazy Services).

The solution is relatively easy (not as much as finding it), and I commited a patch for that, so Drupal Symfony Inject should not have that problem anymore: https://drupal.org/node/2287081.

A different question is, how to use Lazy Loading in our projects when we are not using Symfony 2 framework but its components. One of the errors which we were doing in the Drupal Symfony Inject module was that we were not loading the Proxy Manager Bridge, which makes the integration of Proxy Manager, your code and some other Symfony 2 components.

At that point we were quite lost, not many people has done before that integration between Drupal and Symfony 2 Lazy Loading, so we had very few people to ask, even inside Capgemini itself, and even fewer documentation to consult. Fortunatelly there are some interesting pieces of code in every well designed software. I am talking about test units: https://github.com/symfony/ProxyManagerBridge/blob/master/Tests/LazyProx...

The most interesting part in lines 34 and 37:

$builder->setProxyInstantiator(new RuntimeInstantiator());

That part is essential, it will instantiate the Proxy Manager and substitute your Object with an instance of that Proxy.

We just need to do one last step, indicate that our object will use Lazy Loading:

$builder->getDefinition('your_class')->setLazy(true);

From this point, the next time you load your object:

$builder->get('your_class')

if you ask for the class of this object it will identify itself as a Lazy Proxy:

\ProxyManager\Proxy\LazyLoadingInterface

 That state will remain until you ask the object to return something, basically when you use one of its methods:

$your_object->doSomething();

Now that object will say that he is the real class, something like that:

\ProxyManagerBridgeFooClass

 

More information: