Packages installed from git where the git user has capital letters don't show up in `package list` about package-command

[javorszky]

From the looks of it, this piece of code should handle the mismatch:

https://github.com/wp-cli/package-command/blob/master/src/Package_Command.php#L221-L227

But for some reason doesn't.

[gitlost]

Thanks for the excellent example and diagnostics @javorszky.

this piece of code should handle the mismatch

Composer is doing strtolower()s all over the place for some reason so the package name gets "corrected" to its lowercase version.

A way around might be to do $installed_package_keys = array_map( 'strtolower', $installed_package_keys ); in get_installed_packages(), and also to lowercase the $package_name arg in get_installed_package_by_name() and (for the BC check only) get_package_by_shortened_identifier().

[javorszky]

I think the install script is wrong. It compares the package name in the composer.json in the repo with the name of the repo, and if the two don't match, it uses the name in the composer.json.

Or at least should. If you look in the composer.json of the example command, that one is all lowercase because composer complains otherwise.

Yet what does get installed / recorded is the repo name, so the comparison goes wrong there. I think. I don't have wpcli set up for dev on my computer, so can't double check this with debugging statements.

[gitlost]

I think the install script is wrong. It compares the package name in the composer.json in the repo with the name of the repo, and if the two don't match, it uses the name in the composer.json.

Ah maybe it shouldn't then. If I change that check to if ( strtolower( $package_name ) !== $package_name_on_repo ) { then things kind of work okay, ie the require etc keys in ~/wp.cli/packages/composer.json all have the non-lowercased name.

And with the strtolower() hacks mentioned earlier can uninstall okay as long as I specify the correct case.

The listing is wrongly in lowercase though.

[javorszky]

What I mean is that if the github is CapitalWPCLI/examplecommand, and the composer json has capitalwpcli/examplecommand as the name, it should save as capitalwpcli/examplecommand.

Currently it saves as CapitalWPCLI/examplecommand.

[javorszky]

To be fair, I expect the ~/.wp-cli/package/composer.json would have the name of the package as it's declared in the composer.json of the package.

[gitlost]

Okay, ta. It's very confusing and messy. I'll leave it to the Composer experts, of which I'm most definitely not. Related wp-cli/wp-cli#4232 and #31

[javorszky]

Okies. I summon @schlessera / @danielbachhuber to take a glance at this if they have a moment :)

[gitlost]

Mystery solved - just noticed the 4292472 in your stat of wp - that's the size of wp-cli 1.3.0 - and #31 is only in 1.4.0, so that's why the mixed case git user name is ending up in your composer.json, as it's not getting corrected by mismatch check in the lines you highlighted.

I'll add a test anyway to clarify this situation (for myself mostly, given the confusion I got myself into above).

[javorszky]

Ooh, okay. That makes sense! Thank you. An uh... sorry for not checking the versions! Should I leave this open until the tests are added?

[gitlost]

Hi, thanks for getting back. Please leave it open yes, as I've found out that there is an issue after all with mixed-case names with the current version, though not in your particular case (but when the name in composer.json is mixed-case anyway).

I'm going to do a PR very soon with a fix for that case, and also with tests for that case and your case. The tests will use your test example https://github.com/CapitalWPCLI/examplecommand if that's alright. Also if and when you have the time if you could confirm that updating to the latest wp-cli fixes your issue it'd be much appreciated.

[javorszky]

Will do! I'll keep an eye out for the new versions of wp-cli! Thank you for looking into this!

[gitlost]

Ta - just in case to clarify, the current version 1.4.0 should fix your issue so you don't have to wait to confirm it!

[javorszky]

Hi,

So it didn't work... seemingly it did. Also, if I'm installing a specific package, it shouldn't update all the others, right?

This is using wpcli 1.4.0

[javorszky]

Nope, ignore the above. Once I removed the package manually (delete files, delete composer.lock, edit composer.json), and tried again, it installed the package correctly.

However I can no longer test updating other packages when I'm installing one...

[danielbachhuber]

Also, if I'm installing a specific package, it shouldn't update all the others, right?

Incorrect. This is expected behavior, as WP-CLI uses Composer under the hood.

[gitlost]

Once I removed the package manually (delete files, delete composer.lock, edit composer.json)

Yes, that's the sort of thing I ended up doing too, which I thought was probably just my system having got messed up.

[gitlost]

This is expected behavior

Maybe it shouldn't though?! It seems odd to me that installing a package causes a full install using ~/.wp-cli/packages/composer.json rather than just the package's composer.json (but I'll have to think about it and come up with something less half-formed - and this probably isn't the best place to discuss it anyway).

[schlessera]

Also, if I'm installing a specific package, it shouldn't update all the others, right?

Incorrect. This is expected behavior, as WP-CLI uses Composer under the hood.

Actually, you can do a selective update with Composer.

So, composer update my/package will only update that individual package, not the rest.

[javorszky]

Actually, you can do a selective update with Composer.

So, composer update my/package will only update that individual package, not the rest.

That's fine, but if I'm just installing a package, I don't expect all other packages to be touched unless I explicitly tell them to be touched.

Dunno, maybe it's just me and not knowing what to expect of composer.

[schlessera]

No, you're right, I think. I would also expect that if I add a package, that that package will get installed in its latest matching version, but the rest just stays as is. I should need to run wp package update to get updates to the rest of the packages.