support "activating" gg environments by appending a single directory to `PATH`

[DetachHead]

the problem

in my projects i use pyprojectx, which is basically the same idea as gg but specific to python (it requires python to be installed globally and only supports installing tools from pypi). i've been looking for a language-agnostic alternative for a while so i'm glad to have finally found gg.

when installing a tool via pyprojectx, its executable gets installed to ./.pyprojectx/main, which means you can add that directory to your PATH to be able to run them without using the wrapper script:

export PATH="$PATH:./.pyprojectx/main"
./pw --add uv
uv --version

this allows me to configure vscode to do this, so that any tools required by my project are instantly made available in the PATH for all contributors, without them ever having to install anything globally or change their PATH manually:

// .vscode/settings.json
{
  "terminal.integrated.env.linux": {
    "PATH": "${env:PATH}:${workspaceFolder}/.pyprojectx/main"
  }
}

this is more difficult to do in gg because its tools are installed to separate directories, meaning this config would need to be updated when tools are added or updated.

(more info/context in the pyprojectx feature request: pyprojectx/pyprojectx#23)

proposed solution

i propose adding a .gg directory in the project root, which contains either symlinks or wrapper scripts to the correct versions of the tools defined in gg.toml. for example:

.
└── project_root/
    ├── .gg/
    │   ├── node
    │   ├── uv
    │   ├── uvw
    │   └── uvx
    ├── gg.cmd
    └── gg.toml

this allows us to add the following config to .vscode/settings.json:

// .vscode/settings.json
{
  "terminal.integrated.env.linux": {
    "PATH": "${env:PATH}:${workspaceFolder}/.gg"
  }
}

and now once a tool is installed via gg, it can be executed directly without the wrapper script:

./gg.cmd node --version
node --version # works!

this is also great for IDE integrations that expect certain tools to be available in the PATH.

[eirikb]

When I started on gg I specifically didn't want activation or install scripts. The idea was that while gg runs the env is polluted for tools specified, but once it is done then the environment should no longer be polluted.

If one wants to add more tools to the "run" one would simply add them as dependencies, gg x:y:z.
Meaning if your node script required openapi-generator (does exec on it) and thus java, one could do: gg node:openapi script.js.

But that was then, and while I considered it a noble and fine idea, it might not be that important.
Your idea is good, however it would need some command to "enable" it?
Like opt-in? Such as gg shim

[DetachHead]

But that was then, and while I considered it a noble and fine idea, it might not be that important.

thanks for being open to this idea! i definitely agree that pollution is bad, which is why i seek out tools like this which isolate installations of tools that would otherwise have to be installed globally. but if the project's environment is only activated per project (or explicitly per-shell with an activateion command), i don't see it as pollution

Your idea is good, however it would need some command to "enable" it?
Like opt-in? Such as gg shim

i don't personally use activation commands either, i just configure vscode to do the activation automatically by appending the directory to $PATH. but having a command for it sounds good because most people would probably expect it (at least if they're coming from the python ecosystem)

[DetachHead]

an example of what such a feature could look like: in my project i created a directory of named symlinks to gg.cmd. this way i can add it to my PATH (configured automatically with vscode), so that all my gg dependencies & aliases can be run like normal:

$ uv --version
uv 0.11.26 (x86_64-unknown-linux-gnu)

all gg would need is a command to automatically generate this directory (and dynamically update it when more dependencies & aliases are added to gg.toml)

another thing to consider: does this directory get committed?

• if so, it would need to contain two versions of each symlink: one with a .cmd and one without. as far as i can tell, it's not possible to get the extension-less command to work from the PATH on both linux and windows with a single executable. but the benefit of committing the directory is that anybody cloning the repo doesn't have to run a separate gg.cmd command first (provided the project comes with the vscode config that automatically adds these executables to the PATH)
• if not, gg would only need to generate the symlinks for the current platform (and with a .gitignore file inside it)