search

coenjacobs / mozart

Developers tool for WordPress plugins: Wraps all your projects dependencies in your own namespace, in order to prevent conflicts with other plugins loading the same dependencies in different versions.
https://coenjacobs.me/projects/mozart/
MIT License
426 stars 53 forks source link

PSR-0 Support? #6

Closed Shelob9 closed 4 years ago

Shelob9 commented 7 years ago

I'm trying this out because my Braintree integration uses Composer to load the BrainTree SDK and WooCommerce is using a cut and pasted version of the BrainTree SDK and one of my users has both plugins...

The Braintree PHP SDK uses a PSR-0 autoloader for some reason. When I run motzart they files are copied to the new dependencies dir with no change.

Is there an undcoumented step for PSR-0, or no support? I'm going to attempt to figure this out, if I do, I will put in a PR...

Shelob9 commented 7 years ago

BTW This is my composer.json right now for testing, I added Pimple to confirm it was working with PSR-4 namespaced libraries:

https://pastebin.com/0jcUrWEJ

coenjacobs commented 7 years ago

Hey @Shelob9, sorry for the late - late - reply to this issue. I've finally been able to take some time and reproduce this issue. The Braintree PHP SDK uses nested namespace roots for their autoloader: https://github.com/braintree/braintree_php/blob/master/composer.json#L23...L30 and this is causing Mozart to error out when it tries to copy the same file to the same directory:

> "vendor/bin/mozart" compose
[League\Flysystem\FileExistsException]
File already exists at path: src/Dependencies/Braintree/PaymentMethod.php

After this error occurs, Mozart stops working and will not replace the namespaces in the already copied files, so what you're seeing actually makes sense.

What I need to do, is three things:

coenjacobs commented 6 years ago

Leaving this here, for future reference: https://twitter.com/seldaek/status/918215111252365312

XedinUnknown commented 5 years ago

PSR-0 is gone. It is for versions of PHP that have reached EOL years ago.

coenjacobs commented 4 years ago

I agree with the statement above, PSR-0 should probably be ignored. This can now be addressed though, by using the override_autoload in the configuration. The (duplicate) PSR-0 autoloader should be removed, using that configuration variable, only defining the PSR-4 one.

ChristophWurst commented 4 years ago

This can now be addressed though, by using the override_autoload in the configuration.

I can confirm that this new config option helps with packages like rubix/ml. See https://github.com/coenjacobs/mozart/issues/14 and https://github.com/ChristophWurst/rubix-ml-mozart/commit/597515eefb9070ea49e3d85f0164338b969e2b79 this has nothing to do with psr-0, actually, and is therefore unrelated.