Skip to content

uw: add ./uw shell, warn about bare pixi shell after setup#168

Merged
lmoresi merged 2 commits intodevelopmentfrom
bugfix/uw-shell-subcommand
May 4, 2026
Merged

uw: add ./uw shell, warn about bare pixi shell after setup#168
lmoresi merged 2 commits intodevelopmentfrom
bugfix/uw-shell-subcommand

Conversation

@lmoresi
Copy link
Copy Markdown
Member

@lmoresi lmoresi commented May 4, 2026

Summary

./uw set-env <env> writes the chosen environment to .pixi-env, and every ./uw <cmd> reads it via get_env() and passes -e <env> to pixi. But pixi itself doesn't know .pixi-env exists — a bare pixi shell (or pixi run …) falls back to the env literally named default in pixi.toml, which is the lightweight conda-forge-PETSc env with no nodejs / dev tools.

That's a real first-timer trap (e.g. PR #167's npm install -g … flow fails with "npm: command not found" because the bare shell isn't in a dev env), and the same trap bites people coming back to a machine after a gap.

Two small additions:

  • A. ./uw shell subcommand. exec pixi shell -e $(get_env) — always lands in the env ./uw thinks you're in. Mirrors every other ./uw dispatch case. Listed under Setup: in ./uw --help.
  • B. Friendlier setup tail. After "Setup complete!", ./uw shell is now in the Usage block, and a short Note explains the bare-pixi shell trap.

No changes to pixi.toml. No behaviour change for anything other than the new ./uw shell invocation.

Test plan

  • bash -n uw clean (verified locally)
  • ./uw --help lists shell under Setup
  • ./uw shell opens a pixi shell whose which npm (or other dev-feature binary) resolves into the configured env
  • ./uw setup end-of-wizard now mentions ./uw shell and warns about bare pixi shell
  • pixi shell (bare) still works exactly as before — this PR doesn't change pixi's own default-env behaviour, only adds a ./uw-side wrapper

Underworld development team with AI support from Claude Code

Bare `pixi shell` ignores .pixi-env and uses the literal 'default'
environment in pixi.toml, which is the lightweight conda-forge PETSc
env with no nodejs / dev tools. Users who configure a dev env via
`./uw setup` (or `./uw set-env dev`) and then type `pixi shell` end
up in the wrong env without realising — first-timer trap, also a trap
when returning to a machine after a break.

A. Add `./uw shell` subcommand: `exec pixi shell -e $(get_env)`. Mirrors
   the existing pattern of every other `./uw` command and always lands
   in the env `./uw` thinks you're in. Listed under Setup in --help.

B. After "Setup complete!", advertise `./uw shell` in the Usage block
   and add a one-paragraph Note explaining the bare-pixi-shell trap.

No changes to pixi.toml. No behaviour change for anything other than
the new `./uw shell` invocation.

Underworld development team with AI support from Claude Code (https://claude.com/claude-code)
Copilot AI review requested due to automatic review settings May 4, 2026 21:39
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a ./uw shell convenience command and updates ./uw setup messaging to steer users away from the common “bare pixi shell uses the wrong env” pitfall, aligning interactive shell usage with the environment recorded in .pixi-env.

Changes:

  • Extend ./uw setup completion output to recommend ./uw shell and warn about bare pixi shell / pixi run using pixi’s literal default env.
  • Add shell to ./uw --help under Setup: with an explanation of why it exists.
  • Add a shell dispatch case that executes pixi shell -e "$(get_env)".

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread uw Outdated
Comment on lines +1689 to +1695
shell)
# Activate the env stored in .pixi-env, not pixi's literal 'default'.
# Bare `pixi shell` ignores .pixi-env and falls back to the env named
# 'default' in pixi.toml, which is the lightweight conda-forge PETSc
# env without nodejs / dev tools — a common first-timer trap.
exec $PIXI shell -e "$(get_env)"
;;
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 42ccb25 — kept the existing shell) block at uw:1592 (the one with shift / "$@" arg-forwarding, as you suggested), folded the explanatory comment about the bare-pixi-shell trap into it, and deleted the duplicate block I had added lower down.

Comment thread uw
Comment on lines 970 to 974
Setup:
setup Interactive configuration wizard
set-env NAME Change environment directly
shell Open a pixi shell in the configured env (not pixi's 'default')
ai-tools Configure external AI instruction paths
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 42ccb25 — dropped the new Setup line entirely and updated the existing Development entry to read Interactive pixi shell in the configured env (avoid bare 'pixi shell') so the trap caveat is documented in the one remaining spot.

Address Copilot review on PR #168:

- A `shell)` case already existed at uw:1592 (forwarding extra args via
  shift + "$@") and `shell` was already listed under the Development
  section of --help. The original commit added a second, simpler
  `shell)` case lower in the dispatch and a third `shell` line under
  Setup, both unreachable / confusing duplicates.

- Fold the explanatory comment about the bare-`pixi shell` trap into
  the existing dispatch case. Drop the duplicate dispatch block.

- Drop the duplicate Setup help line. Update the existing Development
  help line to mention the trap so the doc still earns its keep.

The setup-wizard tail message (introduced in 1d1eccc) is unchanged and
still advertises ./uw shell + warns about the bare-pixi-shell pitfall.

Underworld development team with AI support from Claude Code (https://claude.com/claude-code)
@lmoresi lmoresi merged commit 49b7b17 into development May 4, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants