python: use uv2nix for packaging

[domenkozar]

{ pkgs, lib, config, ... }: {
  languages.python.enable = true;

  outputs.myapp = config.languages.python.import ./. {};
}

[github-actions]

🔍 Suggested Reviewers

Based on git blame analysis of the changed lines, the following contributors have significant experience with the modified code:

• @lamalex - 100.0% of changed lines (2 lines)

Please consider reviewing this PR as you have authored significant portions of the code being modified. Your expertise would be valuable! 🙏

This comment was automatically generated by git-blame-auto-reviewer

Last updated: 2025-08-22T03:31:19.046Z

[claude]

Claude finished @domenkozar's task —— View job

---

Code Review Complete

I've reviewed the uv2nix integration changes. Here are my findings focused on areas for improvement:

Review Checklist:

• Read and analyze main Python module changes (src/modules/languages/python.nix)
• Review test coverage and test file changes
• Check for potential bugs and security issues
• Evaluate performance considerations
• Assess code quality and best practices
• Provide comprehensive feedback

Issues Identified

🚨 Security & Reliability Concerns

1. Unsafe file operations without validation (src/modules/languages/python.nix:519-523)

pyprojectToml =
  if builtins.pathExists (path + "/pyproject.toml")
  then builtins.fromTOML (builtins.readFile (path + "/pyproject.toml"))
  else { };

• No validation of TOML content before parsing
• Could fail with malformed TOML files, causing cryptic error messages
• Consider wrapping in try-catch or providing better error handling

2. Missing input validation for packageName (src/modules/languages/python.nix:516)

packageName = args.packageName or (...)

• No validation that packageName is a valid identifier
• Could lead to build failures if packageName contains invalid characters

🐛 Potential Bugs

3. Inconsistent path handling (src/modules/languages/python.nix:534)

pythonSet.mkVirtualEnv "${packageName}-env" workspace.deps.default;

• Package name derivation uses string interpolation without sanitization
• Risk of injection if packageName contains special characters

4. Missing error handling for workspace loading (src/modules/languages/python.nix:508)

workspace = uv2nix.lib.workspace.loadWorkspace { workspaceRoot = path; };

• No handling of cases where workspace loading fails
• Could result in unclear error messages for users

⚡ Performance Issues

5. Redundant file reads (src/modules/languages/python.nix:519-523)

• builtins.pathExists followed by builtins.readFile - could be optimized
• Consider using a single operation with error handling

6. Heavy overlay composition (src/modules/languages/python.nix:529-532)

.overrideScope (lib.composeManyExtensions [
  pyproject-build-systems.overlays.default
  overlay
]);

• Multiple overlay applications could be expensive at evaluation time
• Consider if overlays can be merged more efficiently

🧪 Test Coverage Gaps

7. Limited test scenarios (tests/python-uv-sync/)

• Only tests basic import functionality with a simple project
• Missing tests for:
  • Error handling (malformed pyproject.toml, missing files)
  • Complex project structures with workspaces
  • Package name inference edge cases
  • Integration with existing Python tools

8. Missing integration tests

• No tests verifying the new import function works with different Python versions
• No tests for the interaction between uv2nix import and existing venv/poetry workflows

📝 Code Quality Issues

9. Missing documentation

• Complex workspace loading logic lacks inline comments
• New dependencies (uv2nix, pyproject-nix, etc.) aren't documented for maintainers

10. Inconsistent naming patterns (src/modules/languages/python.nix:534)

pythonSet.mkVirtualEnv "${packageName}-env"

• Hardcoded "-env" suffix could conflict with user expectations
• Consider making the environment name configurable

Recommendations

1. Add error handling around file operations and workspace loading
2. Validate inputs for packageName and path parameters
3. Expand test coverage with edge cases and error scenarios
4. Add inline documentation for complex logic
5. Consider making environment naming configurable
6. Add integration tests with different Python versions

The core functionality looks solid, but these improvements would make it more robust for production use.

---

[cloudflare-workers-and-pages]

Deploying devenv with    Cloudflare Pages

Latest commit:	3480296
Status:	✅  Deploy successful!
Preview URL:	https://b124f7d5.devenv.pages.dev
Branch Preview URL:	https://uv2nix.devenv.pages.dev

View logs

[rawkode]

Excited to try and use this! I've got a uv project. Subscribed.

[takeda]

@rawkode I actually made a module for my own use https://github.com/takeda/devenv-uv2nix (it basically sets up the environment in such way that all the packages are available in the shell) but I'm also excited about it, perhaps this implementation will be done better and I won't need it at all.