Skip to content

Added prompt for direnv allow after .envrc - #439

Merged
mohsenari merged 5 commits into
mainfrom
mohsen--envrc-on-init-3
Jan 10, 2023
Merged

mohsenari merged 5 commits into
mainfrom
mohsen--envrc-on-init-3

Conversation

@mohsenari

Copy link
Copy Markdown
Collaborator

Summary

Title says it
This is step 3 out of 4 for simplifying direnv integration

How was it tested?

  • compile
  • run devbox init
  • confirm it prompts for direnv integration if direnv is installed

@mohsenari
mohsenari requested review from gcurtis, loreto and savil January 7, 2023 00:30
Comment thread internal/impl/devbox.go Outdated
Comment on lines +65 to +67
fmt.Println("Do you want to enable direnv integration for this devbox project?[y/N]")
fmt.Scanln(&result)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

what does this UX look like?

For UX consistency consider using the survey library, like we do elsewhere: https://github.com/jetpack-io/devbox/blob/d3494d605444711bdc5a9588c7ad7b9030cd9cea/internal/cloud/cloud.go#L109

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I think your suggestion makes perfect sense. Initially, I wanted to minimize the size and not add another dependency but the UX is much better with survey package

Base automatically changed from mohsen--envrc-on-init-2 to main January 9, 2023 23:58
@mohsenari
mohsenari force-pushed the mohsen--envrc-on-init-3 branch from a70023d to d780f48 Compare January 10, 2023 00:06
@mohsenari
mohsenari merged commit f48e806 into main Jan 10, 2023
@mohsenari
mohsenari deleted the mohsen--envrc-on-init-3 branch January 10, 2023 00:53
mikeland73 added a commit that referenced this pull request Sep 16, 2026
…de-extension (#2980)

## Summary

Follow-up to #2979. Clears the last **10 open Dependabot alerts** (8
medium, 2 low) — the repo now has zero open alerts. Each manifest was
re-locked using the toolchain its own `devbox.json` provides (via
`devbox shellenv`), then every package in every touched lockfile was
audited against [OSV](https://osv.dev): **283 unique packages, 0
advisories**.

| Location | Change | Alerts cleared |
| --- | --- | --- |
| `examples/development/python/poetry/poetry-demo` | pytest `7.4.4` →
`9.1.1`; python constraint `^3.8` → `^3.10` | #438, #368 |
| `examples/development/python/poetry/poetry-pyproject-subdir/service` |
pytest `7.4.4` → `9.1.1`; python constraint `^3.8` → `^3.10` | #439,
#367 |
| `examples/development/python/pipenv` | lock-only: pytest → `9.1.1`
(grpcio `1.84.0`, etc. moved along) | #366 |
| `examples/data_science/pytorch/basic-example` | lock-only: torch
`2.7.1` → `2.14.0`, setuptools `80.10.2` → `84.0.0` (transitive) | #453,
#440, #403, #402 |
| `vscode-extension` | lock-only: serialize-javascript `7.0.4` → `7.1.1`
| #383 |

### Notes

**pytest needed the Python floor raised.** The tmpdir fix
(GHSA-6w46-j5rx-g56g) only exists in 9.0.3+, and pytest 9 requires
Python ≥ 3.10, so the two poetry examples' `python = "^3.8"` constraint
had to move to `^3.10` for the fix to be reachable. Both examples'
`devbox.json` already install `python@latest`, so nothing changes for
anyone running them through devbox. `pytest = "^7.2.2"` → `"^9.0.3"` is
the only other manifest edit in the PR.

**torch moved to CUDA 13 wheels.** `torch = "^2.7.0"` already admitted
2.14.0, so `pyproject.toml` is untouched, but the Linux extras in the
lock shifted from `nvidia-*-cu12` to CUDA 13 packages (`cuda-toolkit
13.0.3`, `nvidia-cudnn-cu13`, etc.). The wheels bundle their own
runtime, so this matters only for driver version on Linux hosts (CUDA 13
needs a 580+ driver). The nix `cudatoolkit` pinned in that example's
`devbox.lock` is 11.7 from an old nixpkgs and was already mismatched
with the previous cu12 wheels — I left it alone as it's unrelated to the
advisories.

**Pre-existing, not fixed here:** the pytorch example's `poetry install`
fails on main because `pyproject.toml` declares `packages = [{include =
"devbox_cuda_dev"}]` and that directory doesn't exist. `poetry install
--no-root` works; I verified torch 2.14.0 imports and runs on CPU that
way.

**vscode-extension:** the `resolutions` entry already allowed `^7.0.0`,
so only `yarn.lock` moved. While there, `yarn audit` flagged `ajv
6.12.6` (GHSA-2g4f-4pwh-qvx6) and `diff 5.2.0` (GHSA-73rr-hh4g-fpgx);
both patches fall inside existing ranges so they were refreshed too.
`yarn audit --level low` is now clean.

## How was it tested?

- `devbox run test` (poetry-demo) and `devbox run run_test`
(poetry-pyproject-subdir): 1 passed each.
- `devbox run run_test` (pipenv): runs `main.py` successfully.
- pytorch example: `poetry install --no-root` + import/matmul smoke test
→ `torch 2.14.0, numpy 1.26.4, setuptools 84.0.0`.
- vscode-extension: `yarn install --frozen-lockfile`, `yarn compile`,
`yarn lint`, `yarn audit --level low` → 0 vulnerabilities.
- OSV batch query over every package in all five lockfiles → 0
advisories.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants