gemini-cli: build bundle, 0.30.0 -> 0.31.0#493475
Conversation
|
@pedrobrantes @xiaoxiangmoe @FlameFlag @taranarmo what do you think about this change? Is there any reason to bring the whole node_modules tree when there exists a convenient way to package everything into one file? |
|
I am okay with the change as soon as the package works, though my knowledge in Node and JS is not sufficient to answer the rest 😅 |
|
If you use |
|
I had considered switching to a build bundle, but ultimately decided to keep the current implementation that includes
|
|
Should we consider introducing this as a variant rather than a full replacement? Additionally, we could then deprecate Historically, we introduced the The only trade-off is the build-time overhead: unless the bundle variant is cached, users will need to perform a full source build, which is much heavier than simply fetching the pre-built |
|
I have checked and indeed there are some differences in behavior:
I'm just disappointed that we have to bring such a big closure when we only need like 5% of that. |
96e907a to
15f1b7e
Compare
|
I think I've cracked it:
I've also fixed keytar cleanup so that saving API key to the system keychain actually works now! |
|
|
|
Upstream PR google-gemini/gemini-cli#20154 modified the shebang in |
This decreases output path size 15 times and makes package layout a lot closer to gemini-cli-bin, while saving all the features of the native installation.
15f1b7e to
d5725f9
Compare
|
@ljxfstorm, thanks for the notice, I've pushed an update that incorporates your solution from #495738. |
|
This decreases output path size 15 times and makes package layout a lot closer to gemini-cli-bin.
Also includes update to 0.31.0, as it requires some changes in the build process as well:
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.