Question: What do you think about switching to uv ?

Although this is a new technology, it works much faster than poetry, and it also has all the features of working with workspaces that could be very well suited to your modular project structure

uv - https://docs.astral.sh/uv/
uv workspaces - https://docs.astral.sh/uv/concepts/projects/workspaces/

i used to be much more averse to binary compiled software, when i worked at a company where downloading and running binary files like that went against company policy (and was strictly enforced).

now, i don't think poetry is that much of a burden to deal with, but it doesn't support workspaces - so i think it mostly depends on if we want to split up the code into multiple packages. this project used to have (actually still does have) a bunch of unclaimed packages on pypi when this was last attempted. so it is kind of a hassle to go reclaim them all or come up with a new naming scheme or something - and then make good documentation for them (there is not really much good documentation - you kind of have to read the source).

i am not convinced workspaces are out of the question - that is, publishing as different packages - but it is not a burning need at the moment either.

@alexanderankin

@alexanderankin I think that splitting into several packages within one project is not a bad practice, which will give flexibility to the project, since, let's say, milvus has several simultaneously running versions that need to be supported, which is very difficult to do with the general project approach of the general project that you are using now. If I were you, I would focus on SQLAlchemy dialects, which enable the community to expand independently of the main project.

do you have any samples that are available to play around with? like a project with a couple of sub projects that publish separately and have separate lock files --- basically the only link they have with each other is being in the same "monorepo" and being able to be referenced as dependencies with their relative path (but also when published - still have valid resolvable dependency data so that consumers can still consume them as deps?)

@alexanderankin

@alexanderankin It may be difficult for me to find exactly such projects, but I can create an example

needed to run poetry just now and it can neither lock from scratch or update - really moves this ticket up in terms of priority from my point of view

@alexanderankin

I am also facing the problem that poertry seems not to be able to update the depenencies.

I think the problems in a lot of pipelines are deprecated sqlachemies that won't work with newer versions of python.

@alexanderankin could label this Issue as high priority ?

i used to be much more averse to binary compiled software, when i worked at a company where downloading and running binary files like that went against company policy (and was strictly enforced).

I not 100% follow. You can install uv with pip install uv as you can install pip install numpy, that also contains compiled code / binary blobs.
What is the difference?

i would imagine loading a dll that is unsigned triggers the antivirus less, but I'm not sure since I don't use numpy. The company I work at now is becoming SOC 2 compliant, for example, which btw a lot of big corporate in US are, and there is a stipulation that there are restrictions on what software employees can install. I can only imagine this is a way to implement this.

I agree that this is a high priority issue, let me try to recreate the lockfile with latest versions of everything.

Guys, in general, I can try to make a full transfer to uv this New Year's weekend

i think we are ready for that because while #946 fixes the lockfile versions, it took several minutes to lock.

it installs pretty quick though.

i do hear pip has lockfiles now though, maybe we can also try pip in the meantime, for all i know about the python ecosystem it may have had caught back up and taken the lead

I meant not only raising dependencies, but also using a mechanism similar to the sqlalhimia dialect, as well as using a more modern dependency installer.

@Neko1313

Workspaces are not suited for cases in which members have conflicting requirements, or desire a separate virtual environment for each member. In this case, path dependencies are often preferable. For example, rather than grouping albatross and its members in a workspace, you can always define each package as its own independent project, with inter-package dependencies defined as path dependencies in tool.uv.sources:

@Neko1313 maybe first only split into workspaces using uv and a single package with optional dependencies like we have at the moment. Maybe we even don't need workspaces at all atm, while we build a single package.

Do you have a draft already for the conversation?

I have created a repository https://github.com/alexanderankin/example-python-project - the purpose of the repository is to solicit advice on how to set up a python project in 2026. My first step personally would be to ask "can i write it any other language" so I will admit I'm not the best person to ask. I will set up some branches where i try to figure out how to perform tasks with uv, mypy, ruff, docs, perhaps also gha cicd, etc... so if you guys want to see something done differently in this repo, just let me know what you have in mind. you can do that by making a PR to that repo.

What is your exact goal with that project?
Just getting experiences or trying to define good staring place for other users?
Or just a starting place for this repo?

If your goal is starting point for new users, I would look at existing projects first.
In the past I recommended https://github.com/pyscaffold/pyscaffold to start with projects. But given the recent developments with hatch/poetry and later uv it did never catch up. Not even migrated to pyproject.toml only.
If you motivated we could try to restart it again using uv, ruff etc.
I liked this project as it allowed for updates of the template. Updating it to the most recent changes in the ecosystem is a fair amount of work.

In general the problem with the Python ecosystem is, that there are different solution and options about the best tooling is existing, so templates are optionated by default.

If you want to look at good starting points, you can search for recent cookiecutter templates for instance:

All differ a bit. You see not an easy question.

This is great! this is exactly the sort of input that is required here, in my opinion. I hope something here will fit the needs of this project

…

On Sat, Jan 17, 2026 at 8:05 PM Kound ***@***.***> wrote: *CarliJoy* left a comment (testcontainers/testcontainers-python#845) <#845 (comment)> What is your exact goal with that project? Just getting experiences or trying to define good staring place for other users? Or just a starting place for this repo? If your goal is starting point for new users, I would look at existing project first. In the past I recommended https://github.com/pyscaffold/pyscaffold to start with projects. But given the recent developments with hatch/poetry and later uv it did never catch up. Not even migrated to pyproject.toml only. If you motivated we could try to restart it again using uv, ruff etc. I liked this project as it allowed for updates of the template. Updating it to the most recent changes in the ecosystem is a fair amount of work. In general the problem with the Python ecosystem is, that there are different solution and options about the best tooling is existing, so templates are optionated by default. If you want to look at good starting points, you can search for recent cookiecutter <https://github.com/cookiecutter/cookiecutter> template for instance: - https://github.com/bosd/cookiecutter-uv-hypermodern-python - https://pypi.org/project/whiteprints (not cookiecutter but copier) - https://github.com/serafinovsky/cookiecutter-uv-package - https://github.com/wyattferguson/pattern - https://github.com/matrig/minicookiecutter - https://github.com/fpgmaas/cookiecutter-uv All differ a bit. You see not an easy question. — Reply to this email directly, view it on GitHub <#845 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACECGJFHFSOGWZV27UWARBD4HLL4DAVCNFSM6AAAAACBZY3IACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONRUGU2TINBXGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

ill be looking at all of those soon

…

On Sat, Jan 17, 2026 at 9:49 PM David Ankin ***@***.***> wrote: This is great! this is exactly the sort of input that is required here, in my opinion. I hope something here will fit the needs of this project On Sat, Jan 17, 2026 at 8:05 PM Kound ***@***.***> wrote: > *CarliJoy* left a comment (testcontainers/testcontainers-python#845) > <#845 (comment)> > > What is your exact goal with that project? > Just getting experiences or trying to define good staring place for other > users? > Or just a starting place for this repo? > > If your goal is starting point for new users, I would look at existing > project first. > In the past I recommended https://github.com/pyscaffold/pyscaffold to > start with projects. But given the recent developments with hatch/poetry > and later uv it did never catch up. Not even migrated to pyproject.toml > only. > If you motivated we could try to restart it again using uv, ruff etc. > I liked this project as it allowed for updates of the template. Updating > it to the most recent changes in the ecosystem is a fair amount of work. > > In general the problem with the Python ecosystem is, that there are > different solution and options about the best tooling is existing, so > templates are optionated by default. > > If you want to look at good starting points, you can search for recent > cookiecutter <https://github.com/cookiecutter/cookiecutter> template for > instance: > > - https://github.com/bosd/cookiecutter-uv-hypermodern-python > - https://pypi.org/project/whiteprints (not cookiecutter but copier) > - https://github.com/serafinovsky/cookiecutter-uv-package > - https://github.com/wyattferguson/pattern > - https://github.com/matrig/minicookiecutter > - https://github.com/fpgmaas/cookiecutter-uv > > All differ a bit. You see not an easy question. > > — > Reply to this email directly, view it on GitHub > <#845 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACECGJFHFSOGWZV27UWARBD4HLL4DAVCNFSM6AAAAACBZY3IACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONRUGU2TINBXGE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

@CarliJoy

@CarliJoy and I discussed, testcontainers-python will move to uv, we can track in #957

Navigation Menu

Repository navigation

Question: What do you think about switching to uv ? #845

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Question: What do you think about switching to uv ? #845

Description

Activity

alexanderankin commented on Jul 21, 2025

Neko1313 commented on Jul 21, 2025

alexanderankin commented on Aug 7, 2025

Neko1313 commented on Aug 7, 2025

alexanderankin commented on Nov 14, 2025

CarliJoy commented on Jan 4, 2026

alexanderankin commented on Jan 4, 2026

Neko1313 commented on Jan 4, 2026

alexanderankin commented on Jan 4, 2026

alexanderankin commented on Jan 4, 2026

Neko1313 commented on Jan 4, 2026

CarliJoy commented on Jan 4, 2026

alexanderankin commented on Jan 17, 2026

CarliJoy commented on Jan 18, 2026

alexanderankin commented on Jan 18, 2026

alexanderankin commented on Jan 18, 2026

alexanderankin commented on Jan 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions