13 ms·

No one reads the readme anymore? https://github.com/googleapis/google-api-php-client#cleaning-up-unused-services https://github.com/googleapis/google-api-php-cl

by 0x073 5y ago

No one reads the readme anymore? https://github.com/googleapis/google-api-php-client#cleaning-up-unused-services https://github.com/googleapis/google-api-php-client#cleaning... "Cleaning up unused services There are over 200 Google API services. The chances are good that you will not want them all. In order to avoid shipping these dependencies with your code, you can run the Google\Task\Composer::cleanup task and specify the services you want to keep in composer.json:"

KronisLV 5y ago
It feels like some sort of a tree shaking solution in most of our modern development stacks is long overdue. If only we could get rid of dynamically called code and instead could evaluate which code paths the code actually can call, then we'd be able to throw out about 90% of the contents of libraries, since most of the time noone actually uses all of that functionality. Doing that with separate scripts is another approach, but it feels like the problem should be solved at its root.
- yummypaint 5y ago
  This sounds like it could be equivalent to the halting problem
  - herbstein 5y ago
    With a conservative analysis it's possible to make an underestimation on the names one can remove. This shouldn't be done on object files but at a level where program flow information is still preserved. A flow-independent analysis using a superset lattice over the callable names should do the trick for a first-order implementation that will look good enough compared to shipping 37mb for google authentication. Further you could make it flow-sensitive for a more accurate analysis with the caveat that the runtime will be significantly longer.
  - jitl 5y ago
    Control flow graphs are well-studied, critical parts of most compilers. The halting problem involves complexity of semantics in loops and jumps, but it’s possible to understand what loops may run just fine, without being able to decide exactly when a loop may exit. In many cases Clang and GCC compiler can easily understand loops, and even reduce them to constant time.
- MortenToudahl 5y ago
  It sounds like what's already available in C#. https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming-options https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm...
yashg 5y ago
"I tried removing unnecessary services from composer.json. Still 14000+ files."
- 0x073 5y ago
  Validate a User Only: composer.json { "require": { "google/apiclient": "^2.10" }, "scripts": { "pre-autoload-dump": "Google\\Task\\Composer::cleanup" }, "extra": { "google/apiclient-services": [ ] } } => vendor folder size: 6MB, 1012 Files
  - yashg 5y ago
    Cool. I did not remove enough services it seems.
denton-scratch 5y ago
But Composer is the cause of all those file dependencies. Things like Composer and NPM encourage devs to re-use scores of 3rd-party libraries rather than writing new code; those libraries also rely on NPM/Composer; so they also have scores of dependencies. And it's impractical to audit them all. I don't understand why people are so willing to depend on these crazy dependency trees, where most of the code was written by people you don't even know the names of.
- 0x073 5y ago
  Before dependency managers, you downloaded a zip with php files from people you dont even know the names of. (And never update any of the external libraries) These managers dont replace the chain of trust, if you dont trust a dependecy and the developer behind dont install it. "And it's impractical to audit them all." I dont use NPM but for composer.json: https://github.com/fabpot/local-php-security-checker https://github.com/fabpot/local-php-security-checker I agree, composer is not perfect, but before it was worse.

by 0x073 5y ago

KronisLV 5y ago

It feels like some sort of a tree shaking solution in most of our modern development stacks is long overdue. If only we could get rid of dynamically called code and instead could evaluate which code paths the code actually can call, then we'd be able to throw out about 90% of the contents of libraries, since most of the time noone actually uses all of that functionality. Doing that with separate scripts is another approach, but it feels like the problem should be solved at its root.

yummypaint 5y ago
This sounds like it could be equivalent to the halting problem
- herbstein 5y ago
  With a conservative analysis it's possible to make an underestimation on the names one can remove. This shouldn't be done on object files but at a level where program flow information is still preserved. A flow-independent analysis using a superset lattice over the callable names should do the trick for a first-order implementation that will look good enough compared to shipping 37mb for google authentication. Further you could make it flow-sensitive for a more accurate analysis with the caveat that the runtime will be significantly longer.
- jitl 5y ago
  Control flow graphs are well-studied, critical parts of most compilers. The halting problem involves complexity of semantics in loops and jumps, but it’s possible to understand what loops may run just fine, without being able to decide exactly when a loop may exit. In many cases Clang and GCC compiler can easily understand loops, and even reduce them to constant time.
MortenToudahl 5y ago
It sounds like what's already available in C#. https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming-options https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm...

yashg 5y ago

"I tried removing unnecessary services from composer.json. Still 14000+ files."

0x073 5y ago
Validate a User Only: composer.json { "require": { "google/apiclient": "^2.10" }, "scripts": { "pre-autoload-dump": "Google\\Task\\Composer::cleanup" }, "extra": { "google/apiclient-services": [ ] } } => vendor folder size: 6MB, 1012 Files
- yashg 5y ago
  Cool. I did not remove enough services it seems.

denton-scratch 5y ago

But Composer is the cause of all those file dependencies. Things like Composer and NPM encourage devs to re-use scores of 3rd-party libraries rather than writing new code; those libraries also rely on NPM/Composer; so they also have scores of dependencies. And it's impractical to audit them all. I don't understand why people are so willing to depend on these crazy dependency trees, where most of the code was written by people you don't even know the names of.

0x073 5y ago
Before dependency managers, you downloaded a zip with php files from people you dont even know the names of. (And never update any of the external libraries) These managers dont replace the chain of trust, if you dont trust a dependecy and the developer behind dont install it. "And it's impractical to audit them all." I dont use NPM but for composer.json: https://github.com/fabpot/local-php-security-checker https://github.com/fabpot/local-php-security-checker I agree, composer is not perfect, but before it was worse.