[GSoC 2026] Project #2 design alignment: Dora.toml scope and Python isolation MVP

[Harsh-Sahu43]

Hello dora-rs team,

I’ve been exploring Project #2 from the implementation side and wanted to validate the MVP boundary before going further.

From the recent discussion, my understanding is that the first milestone should focus on:

• Python environment isolation
• Dora.toml as an early design artifact
• uv venv as part of the initial workflow
• keeping C/C++ and Rust package/toolchain management out of scope initially

That direction makes sense to me.

I’ve been exploring this area through:

• RFC: RFC: DORA Node Package Ecosystem (Manifest + Registry + Package Manager) #1402
• shared package metadata groundwork: refactor(cli): introduce shared package metadata model #1467
• publish/archive contract groundwork: feat(cli): prototype publish/archive contract for Dora packages #1471

From reading the current Dora build/runtime flow, my current intuition is:

• pyproject.toml should remain the Python packaging/build source of truth
• Dora.toml should complement it by carrying Dora-level package/node metadata
• dora build should materialize the Python environment deterministically
• dora run / dora start should reuse that environment rather than re-resolve/install dependencies at runtime

I’ve already been exploring an initial Dora.toml schema/model direction in #1467 , mainly around:

• package identity
• entrypoint
• description
• dependency sources (version, path, git, rev)

The main design questions I’d appreciate guidance on are:

1. For the Python isolation MVP, is the preferred granularity closer to:

   • one environment per Dora node/package
   • or one environment per dataflow

2. Is it reasonable for the initial Dora.toml scope to stay limited to Dora-level metadata like the above, while leaving Python dependency management itself anchored in pyproject.toml?

3. Is the intended first integration boundary:

   • dora build materializes the environment
   • dora run / dora start reuse it deterministically

My goal is to keep the work incremental and aligned with Dora’s current architecture, rather than pushing a larger package-manager design too early.

Any guidance on that MVP boundary would be very helpful.

Thanks.

[Harsh-Sahu43]

Hi, @bobdingAI,

Update: I’ve started working on a prototype implementation for Dora-managed Python isolation (PR #1515), following the MVP direction discussed (Python-only, uv venv, build-time environment materialization with runtime reuse).

The current prototype assumes a per-node/package environment model, but I’d appreciate confirmation on whether this aligns with the intended granularity for the MVP (per-node vs per-dataflow).

[Harsh-Sahu43]

Hi, @bobdingAI @XxChang,

One clarification for proposal alignment:

Project #2 description currently links dora-rs/adora, but the project text still refers to outcomes like dora install / dora publish, and most of the build/runtime/package-related work I’ve been exploring and contributing to is in dora-rs/dora.

Should Project #2 be expected to target:

• dora-rs/adora
• dora-rs/dora
• or both, depending on the milestone

I want to make sure I’m aligning my proposal and contributions with the intended repository.

[LeonRust]

Hello, in your understanding, is DORA's package management tool for managing code packages (similar to pip, cargo) or for managing distribution packages (similar to Docker)? These two different methods have completely different processing approaches. I'd like to hear your thoughts.

[Harsh-Sahu43]

Thanks, that distinction is very helpful.

After thinking through the current Dora architecture and the scope of Project #2 , my current view is that the MVP is closer to a code-package-manager processing model than to a Docker-style distribution model.

The main reason is that the expected outcomes : package metadata, a registry prototype, dora install / dora publish, lockfile support, and Python runtime isolation, all point toward a package workflow closer to Cargo/crates.io, but scoped to Dora node packages rather than general-purpose Python or Rust libraries.

That is also the direction of the work I have been exploring in #1467, #1471, and #1515: a Dora-level package workflow on top of native language tooling, rather than a container/image-based distribution system.

[LeonRust]

If it's package-based management, DORA currently supports Rust, Python, and C/C++. Suppose a developer only knows Python but needs a package developed in Rust or C/C++, which they don't understand. How can they use this package? Do they have to learn another language? Package-based management involves setting up development environments for different languages, which might create new confusion for a developer who only knows Python.

[Harsh-Sahu43]

How can they use this package? Do they have to learn another language?

My view is no. A Python user should not have to learn Rust or C/C++ just to use a Dora node implemented in those languages.

The author can still work with native tooling such as pyproject.toml, Cargo.toml, or CMake, but the consumer-facing abstraction should be the Dora node package: Dora-level metadata plus dora install / dora publish, rather than requiring users to understand the implementation language.

[LeonRust]

Perhaps I didn't express myself clearly enough. What I meant was that it's a code-based package management system. The packages installed by dora install might be nodes developed in Rust or C/C++, which are all source code. After installation, they need to be compiled before they can be used. How can developers who only know Python compile nodes developed in these languages?

[Harsh-Sahu43]

After installation, they need to be compiled before they can be used. How can developers who only know Python compile nodes developed in these languages?

Thanks! , and sorry for the late reply,

My current view is that a python developer should not have to compile those nodes manually, they would use dora level commands like dora install and dora build , and dora would invoke the node’s native build system instead of requiring the user to work with cargo or cmake directly. For the MVP, if the installed package is source-based Rust or C/C++ , the execution target would still need the corresponding toolchain initially. In longer term, dora could reduce that requirement through stronger build orchestration or prebuilt artifacts, but I do not think the first prototype should assume that yet.

[Harsh-Sahu43]

I also explored some of these ideas concretely in a small prototype repository, dora-package-ecosystem-prototype, mainly to validate Dora.toml, resolver/install/publish flow, registry layout, and local cache behavior. That exploration reinforced for me that Dora’s MVP should stay focused on a Dora-specific package workflow built on top of native language tooling.