[Discussion] Consolidating Python code under one uv workspace

[Yong Zheng <yz...@apache.org>]

Hello team,

I would like to purpose consolidating python code under one uv workspace. Will has compiled a details comparison between different options we have via https://docs.google.com/document/d/1_yk45ZiaSVp4lU5mf4YTP8qigcdsElbytR7_3NlqBTo/edit?tab=t.21hya2bfbvnh.

Currently we are using a separate environment per tool/converter. This lets different packages carry different dependency sets, but it also means they can silently conflict with each other. It does create a good amount of repetitive code around package layout, though it gives us the flexibility to pin a set of dependencies when a converter really needs it.

The main concern I had with a single environment (implemented via a uv workspace) was dependency conflicts. With one lockfile, a conflict in any converter blocks everyone. But if we are likely to have Renovate bots keeping dependencies up to date, I think that concern mostly goes away. Renovate will turn any incompatibility into a reviewable PR against the shared lockfile, and CI will catch it before it lands. With separate environments, those conflicts stay hidden until they hit runtime. So a single lockfile isn't really giving up flexibility — it's moving the conflict from "we'll find out later" to "we'll find out now."

Given that, going with the uv workspace seems advisable: one uv sync, one uv.lock, shared ruff rules, and tests runnable from the root. We can still build and publish a wheel per converter from that shared environment, and any genuinely independent converter can stay outside the workspace and plug in via the CLI plugin model.

Thoughts?

Thanks,
Yong Zheng 

Re: [Discussion] Consolidating Python code under one uv workspace

[Yufei Gu <fl...@gmail.com>]

Thanks Yong and JB! We touched on this in the last community sync and
ontology sync. I think it would help to clarify the intended scope of
converters in the main repository.

*Should all converters, including future ones, live in the main repository?
*Probably not. Most converters are tied to specific platforms, so
maintaining them in separate repositories or on the vendor side may make
more sense. Whether the main repository should continue accepting new
converters is a community decision.

*Should we still provide converters and validators in the main repository?*
I think so. Reference impl. would be useful for demonstrating how the spec
works and for testing and validating proposed ideas before they are
formalized in the spec.

*What about the converters already in the repository? *We could review them
case by case with their maintainers. I’d suggest keeping converters that
demonstrate the spec clearly, run without platform access, and are
manageable for the community to maintain. A small set could cover different
spec features. Converters that require substantial platform infrastructure
or frequent vendor-specific updates could move to separate repositories,
with agreement from their maintainers and the community.

*Should these long-term decisions block adopting a uv workspace?* I don’t
think so. Making the Ossie repository more maintainable is the broader
goal, and adopting a uv workspace is a step toward that goal. We can
improve the dev setup now while continuing to discuss where each converter
belongs, provided we preserve each converter’s independence.

Yufei


Yufei


On Sun, Sep 6, 2026 at 12:14 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi Yong,
>
> Thanks for bringing this up.
>
> I still advocate for keeping each converter separate and atomic,
> meaning nothing should be shared for the build between converters
> aside from dependencies. Eventually, we might even consider moving
> each converter to a separate GitHub repository, though I don't think
> we need to do that just yet.
>
> I am fine with using uv workspace, provided that:
>
> 1.  Each converter remains atomic, maintaining its own release cycle,
> implementation details, and build process.
> 2.  Converters can leverage common components.
>
> As a side note for Will: while using Google Docs is completely fine,
> please ensure that all discussions are conveyed on the mailing list.
> At the ASF, everything should happen on the list.
>
> Regards,
> JB
>
> On Sun, Sep 6, 2026 at 9:05 AM Yong Zheng <yz...@apache.org> wrote:
> >
> > Hello team,
> >
> > I would like to purpose consolidating python code under one uv
> workspace. Will has compiled a details comparison between different options
> we have via
> https://docs.google.com/document/d/1_yk45ZiaSVp4lU5mf4YTP8qigcdsElbytR7_3NlqBTo/edit?tab=t.21hya2bfbvnh
> .
> >
> > Currently we are using a separate environment per tool/converter. This
> lets different packages carry different dependency sets, but it also means
> they can silently conflict with each other. It does create a good amount of
> repetitive code around package layout, though it gives us the flexibility
> to pin a set of dependencies when a converter really needs it.
> >
> > The main concern I had with a single environment (implemented via a uv
> workspace) was dependency conflicts. With one lockfile, a conflict in any
> converter blocks everyone. But if we are likely to have Renovate bots
> keeping dependencies up to date, I think that concern mostly goes away.
> Renovate will turn any incompatibility into a reviewable PR against the
> shared lockfile, and CI will catch it before it lands. With separate
> environments, those conflicts stay hidden until they hit runtime. So a
> single lockfile isn't really giving up flexibility — it's moving the
> conflict from "we'll find out later" to "we'll find out now."
> >
> > Given that, going with the uv workspace seems advisable: one uv sync,
> one uv.lock, shared ruff rules, and tests runnable from the root. We can
> still build and publish a wheel per converter from that shared environment,
> and any genuinely independent converter can stay outside the workspace and
> plug in via the CLI plugin model.
> >
> > Thoughts?
> >
> > Thanks,
> > Yong Zheng
> >
>

Re: [Discussion] Consolidating Python code under one uv workspace

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Yong,

Thanks for bringing this up.

I still advocate for keeping each converter separate and atomic,
meaning nothing should be shared for the build between converters
aside from dependencies. Eventually, we might even consider moving
each converter to a separate GitHub repository, though I don't think
we need to do that just yet.

I am fine with using uv workspace, provided that:

1.  Each converter remains atomic, maintaining its own release cycle,
implementation details, and build process.
2.  Converters can leverage common components.

As a side note for Will: while using Google Docs is completely fine,
please ensure that all discussions are conveyed on the mailing list.
At the ASF, everything should happen on the list.

Regards,
JB

On Sun, Sep 6, 2026 at 9:05 AM Yong Zheng <yz...@apache.org> wrote:
>
> Hello team,
>
> I would like to purpose consolidating python code under one uv workspace. Will has compiled a details comparison between different options we have via https://docs.google.com/document/d/1_yk45ZiaSVp4lU5mf4YTP8qigcdsElbytR7_3NlqBTo/edit?tab=t.21hya2bfbvnh.
>
> Currently we are using a separate environment per tool/converter. This lets different packages carry different dependency sets, but it also means they can silently conflict with each other. It does create a good amount of repetitive code around package layout, though it gives us the flexibility to pin a set of dependencies when a converter really needs it.
>
> The main concern I had with a single environment (implemented via a uv workspace) was dependency conflicts. With one lockfile, a conflict in any converter blocks everyone. But if we are likely to have Renovate bots keeping dependencies up to date, I think that concern mostly goes away. Renovate will turn any incompatibility into a reviewable PR against the shared lockfile, and CI will catch it before it lands. With separate environments, those conflicts stay hidden until they hit runtime. So a single lockfile isn't really giving up flexibility — it's moving the conflict from "we'll find out later" to "we'll find out now."
>
> Given that, going with the uv workspace seems advisable: one uv sync, one uv.lock, shared ruff rules, and tests runnable from the root. We can still build and publish a wheel per converter from that shared environment, and any genuinely independent converter can stay outside the workspace and plug in via the CLI plugin model.
>
> Thoughts?
>
> Thanks,
> Yong Zheng
>