These are chat archives for composer/composer

6th
Sep 2017
still-dreaming-1
@still-dreaming-1
Sep 06 2017 03:13
I'm trying to use a local git repo as a package and I am getting InvalidArgumentException No driver found to handle VCS repository home/jesse/hacking/PurposefulPhp
The location of the local repo is definitely a git repo as in it does have commits
It also has a composer.json file setup
It gives itself a name: "name": "still-dreaming-1/PurposefulPhp"
When I run composer install or composer update from the local package everything seems good
But when I run composer update from the project trying to use that local package I get that error
still-dreaming-1
@still-dreaming-1
Sep 06 2017 03:21
The project trying to use it sets up the "repositories" section of the composer.json and the "require" section to use the local package. Under repositories, the type is set as "vcs", and the "url" is set to the full local path to the directory. That directory contains the composer.json file.
still-dreaming-1
@still-dreaming-1
Sep 06 2017 03:27
ah, got it, was missing the / a the start of the path to the directory...
Hm. I still can't actually use classes from it though...
They were added to the vendor directory, so it is at least partly working...
still-dreaming-1
@still-dreaming-1
Sep 06 2017 03:35
strangely enough I'm getting a use of undefined constant error when I try to refer to the namespace from the local package...
Mike Schinkel
@mikeschinkel
Sep 06 2017 11:31

Hi all - I have run into an issue and wanted to make sure I was not missing something.

I created a Composer installer specific to WordPress whose directories differ from the default composer/installers. The composer/installers defaults to the WordPress standard but ironically the WordPress standard does not work with with Composer if you want Composer to manage WordPress core. If you are interested in the specifics you can see this for more information.

Anyway, some of my dependencies are calling composer/installers and it seems that Composer takes whichever one comes first with no way to set priority, other than to add a bunch of .extra.installer-paths to the project's composer.jsonwhich I am trying to avoid by creating a single Composer plugin WordPress developers can include without having to learn as much syntax. I tried reorganizing the order of plugin dependencies in my composer.json file but it seems that the dependency resolver overrides my order.

So, am I correct, there is no standard approach to set priority for a plugin if another plugin defines the path for the same package type?

I was able to get it to work, at least I think so, after about 6 hours of debugging and basically duplicating all the methods for InstallationManager in my own WordPressInstallationManager class that always makes sure my installer get priority. I don't really like this approach because it a lot of code and might not work if Composer adds methods to InstallationManager, but especially because it hijacks priority can doesn't let anyone else override it if need be (reminds my of the old DOS keyboard interrupt hijacking of programs like SideKick -- always making sure they we the first to see the keystroke -- for those of you who were around way back then. And that caused problems too.)

Here is the relevant code, in two (2) places:

TL;DR? Can I set priority for a plugin to allow it to override $installer->supports($package_type) for other plugins and if not, are the powers that be open to offering a way to do so, or do I have to continue using my hack?

still-dreaming-1
@still-dreaming-1
Sep 06 2017 12:52
also, isn't it supposed to just use a symlink of the files? It is using an older committed version of the file. I just want it to use the latest files there.
still-dreaming-1
@still-dreaming-1
Sep 06 2017 13:05
I did requite it using the @dev version
*require
still-dreaming-1
@still-dreaming-1
Sep 06 2017 15:00
Ok, I got it all working. I needed to change the repository type to "path"
after that I was still getting a strange constant error when trying to instantiate a class
I figured out I needed to remove a "1" at the end of a namespace name
I thought namespace names are allowed to have the same types of names as variables and classes?
still-dreaming-1
@still-dreaming-1
Sep 06 2017 15:12
So I just tried using that namespace name from within the package with the 1 in it and it works fine. But apparently that is an invalid name for a composer namespace, or something like that.
It might be an autoloading bug: "autoload": {"psr-4": { "StillDreaming1\PurposefulPhp\": "src/" }}
Owen Melbourne
@OwenMelbz
Sep 06 2017 15:19
double back slashes
StillDreaming1\\PurposefulPhp style i believe
still-dreaming-1
@still-dreaming-1
Sep 06 2017 15:22
Sorry I should have backticked it. It has double: "psr-4": { "StillDreaming1\\PurposefulPhp\\": "src/" }
still-dreaming-1
@still-dreaming-1
Sep 06 2017 15:40
Even strange is that this is also not working right: "psr-4": { "StillDreamingOne\\PurposefulPhp\\": "src/" }
But this works just fine: psr-4": { "StillDreaming\\PurposefulPhp\\": "src/"
  • sorry can't type: "psr-4": { "StillDreaming\\PurposefulPhp\\": "src/" }
Owen Melbourne
@OwenMelbz
Sep 06 2017 15:42
autoloader already dumped? try redumping it?
still-dreaming-1
@still-dreaming-1
Sep 06 2017 15:50
Ok, just tried that. It is still not working, but I was already doing a composer update in both places before. I guess I should try deleting my vendor directory in both places and do a fresh composer install in both places.
Oh, I forgot to mention, the problem I am getting now is simply a class not found error, so at least it is less strange than some constant not found error.
Yup still having the same error: Class 'StillDreamingOne\PurposefulPhp\Contractor' not found
still-dreaming-1
@still-dreaming-1
Sep 06 2017 23:48
This really doesn't make any sense, I tried adding other letters to the end that have nothing to do with numbers at it doesn't work, it only works with StillDreaming