# \[ANN\] Unified Julia-Python Project Management

**URL:** <https://discourse.julialang.org/t/ann-unified-julia-python-project-management/138676>\
**Category:** Tooling\
**Tags:** announcement, python, cli, developer-tools\
**Created:** [August 7, 2026, 10:46pm UTC](https://discourse.julialang.org/t/ann-unified-julia-python-project-management/138676 "2026-08-07T22:46:36Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![alt-f4-dev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alt-f4-dev/32/223272_2.png) [@alt-f4-dev](https://discourse.julialang.org/u/alt-f4-dev)\
**Post date:** [August 7, 2026, 10:46pm UTC](https://discourse.julialang.org/t/ann-unified-julia-python-project-management/138676/1 "2026-08-07T22:46:36Z")

</div>

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

I’ve been working on [`jupy-cli`](https://github.com/alt-f4-dev/jupy-cli), which is a small cross-platform CLI for hybrid Julia–Python projects. The main idea is to treat the project environments

```plaintext
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:

```bash
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:

```julia-auto
                     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](https://github.com/alt-f4-dev/jupy-cli)

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [August 8, 2026, 1:41am UTC](https://discourse.julialang.org/t/ann-unified-julia-python-project-management/138676/2 "2026-08-08T01:41:57Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![alt-f4-dev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alt-f4-dev/32/223272_2.png) [@alt-f4-dev](https://discourse.julialang.org/u/alt-f4-dev)\
**Post date:** [August 10, 2026, 2:36pm UTC](https://discourse.julialang.org/t/ann-unified-julia-python-project-management/138676/3 "2026-08-10T14:36:26Z")

</div>

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.