You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Question: What do you think about switching to uv ? #845
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
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 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?)
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.
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.
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.
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:
Activity
alexanderankin commentedon Jul 21, 2025
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.
Neko1313 commentedon Jul 21, 2025
@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.
alexanderankin commentedon Aug 7, 2025
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?)
Neko1313 commentedon Aug 7, 2025
@alexanderankin It may be difficult for me to find exactly such projects, but I can create an example
alexanderankin commentedon Nov 14, 2025
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
CarliJoy commentedon Jan 4, 2026
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 not 100% follow. You can install uv with
pip install uvas you can installpip install numpy, that also contains compiled code / binary blobs.What is the difference?
alexanderankin commentedon Jan 4, 2026
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.
Neko1313 commentedon Jan 4, 2026
Guys, in general, I can try to make a full transfer to uv this New Year's weekend
alexanderankin commentedon Jan 4, 2026
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.
alexanderankin commentedon Jan 4, 2026
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
Neko1313 commentedon Jan 4, 2026
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.
CarliJoy commentedon Jan 4, 2026
@Neko1313 maybe first only split into workspaces using
uvand 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?
alexanderankin commentedon Jan 17, 2026
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.
CarliJoy commentedon Jan 18, 2026
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/poetryand lateruvit did never catch up. Not even migrated topyproject.tomlonly.If you motivated we could try to restart it again using
uv,ruffetc.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.
alexanderankin commentedon Jan 18, 2026
alexanderankin commentedon Jan 18, 2026
alexanderankin commentedon Jan 24, 2026
@CarliJoy and I discussed, testcontainers-python will move to uv, we can track in #957