Re: [new] gemini-cli-0.26.0

On 2/16/26 17:14, Stuart Henderson wrote:
> On 2026/02/16 15:23, Kirill A. Korinsky wrote:
>> And, finally, I think part of package.json and tarball can be generalized
>> and extracted into lang/node MODULE, but it is "future refactoring".
>
> I don't think the "build a tarball" approach is general enough to
> put into a module. (Some node-based software wants different deps on
> different archs, so it gets really messy, see zigbee2mqtt...)

Since they moved to pnpm, you could use --force to make all os/arch cache.
A simple pnpm port without patches should be easy to do (no build).

But npm doesn't have --force and I don't know about yarn but I guess it doesn't.
So the pre-made cache may not be an option depending on the port.

>
> (btw I tested gemini-cli build on aarch64, no problems seen)
>
> See the stuff armani@ and Fabien Romano have for a different way to do
> it, that's likely to be a better approach for a module. https://github.com/opencrew-tech/
>

The most advanced module is pnpm.
https://github.com/opencrew-tech/openbsd-electron/tree/main/devel/pnpm

The main problem with those package managers is the way they set up the cache.
Yarn (classic) is the easiest one as the cache is a flat directory.

pnpm has patches to do 'pnpm cache add <spec>|<tgz>' & load <tgz> as <spec>.
We can pre-fetch each tgz and then load them for offline use.

For npm and yarn berry I have ongoing patches. The cache stuff looks ok now.
I should be able to update the whole tree of Electron app this month.

Electron move to yarn berry.
The npm module (on github) lack features and is too fragile.

After all modules converge to the same pattern,
I plan to merge everything into a single devel/node module.
I will try to upstream those patches for sure.

You can already compare with yarn (classic), it's almost the same as pnpm.
https://github.com/opencrew-tech/openbsd-electron/blob/main/devel/yarn/

The main difference with other modules is the way it populates your port.
To make all of this work we have to bundle CONFIGFILES:
package.json, pnpm-lock.yaml, .pnpmrc, pnpm-workspace.yaml
[... each manager have its files]

Thus, when you run mod*-gen-modules, it will:
extract in a temp dir as your user,
fix config files,
customize package.json if needed,
adjust lock file with internet access (as your user) if needed,
run the perl helper to convert the lock into module.*.inc,
And finally write directly into the ports directory (files/* & modules.*.inc).

Also, system install and workspace are tricky to handle correctly.
And even more tricky when using custom depends from ports (overrides).

I'm still far from the end, so there is no documentation yet.
I will have to port more stuff just to be confident we cover most use cases.
Feel free to ping me if you would like to experiment a port using this.

--
Fabien Romano