Google-api-php-client: Improve management of package files - two real-world problems

[pgorod]

Hey. Thanks for this awesome package. I use an open-source CRM called SuiteCRM and we introduced this dependency a few months ago to use Google Calendar API.

We've seen users run into problems installing and upgrading, and these are not bugs, strictly speaking, just things it would be nice to avoid, if possible.

1. On Windows, long file name limit exceeded.

Installer fails when copying file
D:/CRM/SugarCRM/apps/SuiteCRM/htdocs/cache/upgrades/temp/7524.tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.10/vendor/google/apiclient-services/src/Google/Service/Dialogflow/GoogleCloudDialogflowV2beta1IntentMessageBrowseCarouselCardBrowseCarouselCardItemOpenUrlAction.php
That's 262 characters. Windows only allows 260 for path+filename. Depending on the path where each user is installing it, it can exceed the limit.

2. On low-resource shared hostings, problems with package size and file count

We just need Google Calendar API, but adding "google/apiclient": "^2.0" to our composer.json brings in 53 MB, and 10K + files. Note that we ship a complete vendor directory so that users don't have to run composer install.

Both things have caused broken installs or upgrades for our users. Big packages exceed php.ini upload limits, file count caused our (admittedly old and bad) copy files code to exceed max_execution_time (we improved that, it's much faster now).

---

I realize these are not necessarily bugs but I think some attention to them would be good. We would love to be able to use one Google API from Composer without all of those files.

And those big file names, it's probably best to get rid of them...

[jdpedrie]

Hi @pgorod,

Thanks for the details here. Some of this are things we've been considering, but I didn't know we had a filename quite that long.

As for your immediate situation, since you are shipping the already installed vendor directory, you could simply delete all the files and folders from vendor/google/apiclient-services/src which you are not using. If you are only using the Calendar API, you could delete everything but src/Calendar.php and src/Calendar/*.

[fgilio]

👋🏼 Hello!
I want to add a little more emphasis to this issue. We're deploying to a somewhat constrained infrastructure in AWS Lambda that allows up to 250MB, and right now 1/5 of that is consumed just by this package:

I know about this packaged that has an interesting approach at solving this issue: https://github.com/async-aws/aws

---

We'll try deleting the portions of the SDK that we don't use, thanks for the recommendation!

[fhinkel]

Greetings, we're closing this. Looks like the issue got resolved. Please let us know if the issue needs to be reopened.

[pgorod]

Hi! To my knowledge, the issues are not resolved. If any changes were actually made to address these issues, it would be nice to mention them here.

Thanks!

[jdpedrie]

@pgorod We recently added a post-install script you can use to cleanup unused services. The long file name may still pose a problem on Windows, however.

[pgorod]

@jdpedrie thanks for the update, we'll try to use that!

About the long filenames, what is the point of having a file with a name like GoogleCloudDialogflowV2beta1IntentMessageBrowseCarouselCardBrowseCarouselCardItemOpenUrlAction.php?

Is that some convention building the file name from pieces? Would it be hard to change?

[jdpedrie]

These clients are generated from JSON Schemas published by the various API teams. Names are taken from those documents. You can see here that Dialogflow uses a verbose naming convention for the objects in their API.

Since those of us who manage the client library don't control the schemas published by the API team, we unfortunately have limited control over this. We'll continue to think this over and see what can be done, but we have to be careful that changes don't have unintended consequences across a very wide range of clients, so it's tricky.