[ANN] Unified Julia-Python Project Management

Tooling
, , ,
1

[ANN] Unified Julia–Python project management ( jupy-cli )

I’ve been working on jupy-cli, which is a small cross-platform CLI for hybrid Julia–Python projects. The main idea is to treat the project environments

Project.toml
Manifest.toml
.venv/
requirements.txt

as one full project rather than two separately managed environments.

Julia dependencies are still handled by Pkg.jl, Python dependencies by pip, and interoperability is managed by PythonCall.jl. The jupy CLI adds a project-level layer that coordinates them.

The basic workflow is:

jupy                     # initialize/enter the project
jupip install numpy      # pip into the project's .venv
jupy simulation.jl       # Julia with the project active
jupy analysis.py         # Python through the same .venv
jupyup                   # update the CLI

PythonCall is configured to use the same project-local .venv, so Julia and Python execution share a consistent Python environment within a single root directory.

I think of it as a lightweight meta-manager that lives above Pkg, pip, and PythonCall, rather than a replacement for any of them.

Here’s a pretty diagram of the model:

                     jupy
                      │
                    project/
                      │
        ┌─────────────┴─────────────┐
        │                           │
   native Julia                 native Python
        │                           │
     Pkg.jl                        pip
        │                           │
  Project.toml                   .venv/
 Manifest.toml               requirements.txt
        │                           │
        └──────── PythonCall ───────┘

The current release is v0.0.2, with CI on Linux, macOS, and Windows.

I’d particularly appreciate feedback on the environment model, PythonCall/CondaPkg interactions, and edge cases I may have missed.

Repository: GitHub - alt-f4-dev/jupy-cli: Command line interface for running Julia REPL with local Python environment integration. · GitHub

2

I would use pixi to manage pip and conda packages. CondaPkg.jl can be configured to use pixi as well.

3

Thanks for the suggestion! CondaPkg.jl + Pixi is definitely a reasonable approach. Though, my choice of pip by default was intentional. Pixi and Conda operate as broader, language-agnostic environment/package managers, whereas pip is specifically the native installer for Python/PyPI packages.

The goal of jupy-cli is to keep each language’s native package workflow (Pkg.jl for Julia, pip for Python) and coordinate them one level above. I don’t currently plan to make Conda/Pixi the default, but PythonCall.jl / CondaPkg.jl can still be configured through the existing environment-variable interface when that workflow is preferred.

I appreciate the suggestion, and I’d be interested to hear if you see any particular Pixi / CondaPkg.jl workflows that this design would make unnecessarily difficult.