better venv management

[jeremyschlatter]

Advantages over the previous approach:

• watches .python-version, pyproject.toml, and uv.lock

  The previous version checked pyproject.toml in hello.pdf and hello.svg, but nowhere else. It also didn't check .python-version or uv.lock at all. Together these allow lots of commands to run with outdated venvs.

  The new version refreshes the venv immediately when any of those files change.

• removes venv code from build.ninja, keeps it all in .envrc

  This is a strict code simplification, and assuming we never run ninja without direnv, it doesn't lose us anything.

• simplifies venv sourcing logic

  From this:

  export VIRTUAL_ENV="${PWD}/.venv"
  PATH_add .venv/bin
  

  To this:

  source_env .venv/bin/activate
  

[jeremyschlatter]

See discussion here: https://palisaderesearch.slack.com/archives/C09TUDD2YGZ/p1768513935602679

[gemini-code-assist]

Summary of Changes

Hello @jeremyschlatter, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the project's virtual environment management. By consolidating venv logic into .envrc and introducing automatic refreshes based on key configuration files, it aims to create a more robust and user-friendly development setup. These changes reduce manual intervention and potential inconsistencies, leading to a more reliable and efficient workflow for managing Python dependencies.

Highlights

• Automated Virtual Environment Refresh: The system now automatically refreshes the virtual environment when changes are detected in .python-version, pyproject.toml, or uv.lock, ensuring dependencies are always up-to-date.
• Centralized Venv Management: Virtual environment setup logic has been moved from build.ninja entirely into .envrc, simplifying the build configuration.
• Streamlined Venv Activation: The method for sourcing the virtual environment in .envrc has been simplified for cleaner and more concise configuration.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request significantly improves virtual environment management by moving the logic from build.ninja to .envrc. This simplification, combined with watching key dependency files like .python-version, pyproject.toml, and uv.lock, ensures the venv is consistently up-to-date. The changes are a great step forward in terms of developer experience and project maintainability. I have one suggestion to further optimize the environment loading performance.

[dmitrii-palisaderesearch]

I endorse. Could either of @jeremyschlatter @sergey-koldyba figure out what's wrong with CI and merge? Thanks!

[jeremyschlatter]

No visual diff, just a metadata change:

diff --git a/paper-typst/hello.svg b/paper-typst/hello.svg
index 542ceec..77d2826 100644
--- a/paper-typst/hello.svg
+++ b/paper-typst/hello.svg
@@ -10,7 +10,7 @@
     <dc:format>image/svg+xml</dc:format>
     <dc:creator>
      <cc:Agent>
-      <dc:title>Matplotlib v3.10.0, https://matplotlib.org/</dc:title>
+      <dc:title>Matplotlib v3.10.8, https://matplotlib.org/</dc:title>
      </cc:Agent>
     </dc:creator>
    </cc:Work>

[jeremyschlatter]

CI failed because this change had the side effect of updating the version of matplotlib in uv.lock. That in turn caused the figures to change because they include the version of matplotlib in their metadata, and CI caught that I hadn't committed the new version of the figures.

While I was debugging that, I noticed that I had made a mistake in removing pyproject.toml from the build inputs to the figures and paper. The direnv hook ensures that the local venv is up to date, but it doesn't on its own ensure that ninja re-runs the build when that venv changes. Updated the PR to add pyproject.toml back as a build input, along with uv.lock and .python-version.

CI is now passing.