package takes a lot of disc space

[staabm]

If you are still having issues, please be sure to include as much information as possible:

Environment details

• OS: Ubuntu 23 LTS
• PHP version: php 8.1
• Package name and version: google/apiclient-services 0.275

Steps to reproduce

1. install the package via composer require google/apiclient

-> see composer installing a ~100MB dependency folder

having to copy 100 MB of files arround in a continous deployment setup is a real problem.
is there anything which can be done to reduce the filesystem footprint of this package?

here you can see the subfolders within src which contribute the most to filesystem consumption:

Code example

# example

Making sure to follow these steps will guarantee the quickest resolution possible.

Thanks!

[AndreSchwarzer]

PR #1730 seems to be related

[bshaffer]

Also check out doing a limited install, which allows you to declare only the services you want in your composer.json, add a hook in pre-autoload-dump, and all other services will be removed after composer installs the package.

[stof]

The solution to that would be to offer separate packages for the API client of each service. Most projects probably use only a few services.

[bilogic]

The solution to that would be to offer separate packages for the API client of each service. Most projects probably use only a few services.

google is adamantly proud of their mono repo consisting of over a billion lines of code

[marabucz]

It doesn't really makes a sense to have one huge package monster containing everything. Can't this be split into different packages with dependencies?

I mean I only need google analytics, but I end up with ~250 different packages I don't really need, which only make autoload really big, and take space while they'll never be used.

[bshaffer]

The solution to that would be to offer separate packages for the API client of each service. Most projects probably use only a few services.

@stof Unfortunately the limitation of composer is that we'd need to maintain 250 separate github repos, which is not feasible for a number of reasons. There are potentially other ways we could host 250 packages, and we should definitely explore this. But the truth is, these libraries are supported essentially out of altruism at this point as we ship much better individual packages at https://cloud.google.com/php/docs/reference. I understand that not all of our client libraries are covered by the new packages, and if there's a feasible solution (for instance, if packagist supported multiple packages in a single repo), we'd be happy to support it as well.

[stof]

The blocker for packagist to support multiple packages in a single repo is that packagist.org does not manage downloadable archives at all. It only links to the github archive endpoint. And github does not have endpoints download an archive of only a sub-path.

[stof]

Apparently, the google/cloud package manages to be split into subtree repo for the various google/cloud-* packages. So maybe there is already the infrastructure to manage the needed repos.

anyway, maybe the readme of this repo should link to the cloud packages, suggesting to use them when available.

[bshaffer]

Yes and it's a lot of overhead and isn't scalable for 250+ additional packages of a turned down library maintained by a team of essentially me.

I've updated the READMEs: #2279

[bshaffer]

@marabucz I suggest using the Google analytics data package
(google/analytics-data) or the Google analytics admin package (google/anayltics-admin) instead.