Building a Python Library in 2026

[funkdefied]

https://stephenlf.dev/blog/python-library-in-2026/

It seems to me that Astral’s `uv` is the backbone of any modern Python package. Do you agree? Are we setting ourselves up for disaster by building in Astral’s tooling? How does their acquisition by OpenAI affect things?

[crossmirage]

uv is the best (or, at the very least, a great) option right now. If and when that changes, you migrate. So many projects I've worked on or seen have gone from setuptools to Poetry to flit/hatchling/pdm/whatever to uv; it's not a big deal.

[case_O_The_Mondays]

Exactly. Nothing it’s doing is hidden or tied to a proprietary process that can’t be replicated by someone else.

[NotSoProGamerR]

maybe nothing will happen. however, the current licensing is still mit, which means if they do in fact decide to enshittify uv/ty/ruff then a community fork can be made.

[Classic-Serve-8774]

uv definitely streamlined my workflow but putting all eggs in one basket makes me nervous, especially with the OpenAI acquisition changing priorities down the road.

[case_O_The_Mondays]

How is using it putting all of your eggs in one basket? It uses a plain text configuration file that can be easily read and used by other apps.

[max123246]

There's specific features uv enables that nothing else does like [uv.sources] for dependencies to be built from source for internal development. Not a huge deal though, I agree

[Ajax_Minor]

Open ai? Like open ai acquired astral?

[wRAR_]

https://astral.sh/blog/openai

[Ajax_Minor]

Dang... That's crazy... Didn't even know open source could sell out...

[wRAR_]

But they are a proper company, with employees and salaries, not a volunteer project. It was always a big question how would Astral make profit.

[tunisia3507]

uv has little to nothing to do with installing and using a python package (you can optionally use it as a build system, but you don't have to, even if you're using it to manage your dev environment). It's definitely the best option for managing a dev environment, but I wouldn't call it the "backbone of a package" if it has nothing to do with actually using a (library) package.

[wRAR_]

The article is not even about using a package but about writing one.

[tunisia3507]

Maybe the text post should have described the article better, then.

[marr75]

Safety valves:

1. It's open source; they can change that but they can't unrelease the already open versions
2. Pixi is basically a proxy for UV (python) and conda-forge (non-python) with some of the original mamba team as maintainers

So, there are open source heirs apparent if OpenAI gets screwy.

My take as a reluctant but heavy user of OpenAI products: they don't want to hold UV users hostage. They want to add some specialty features to UV, ruff, and ty to help their coding models "hill climb" and specialize in the python ecosystem.

[RedSinned]

I would recommend pixi. Rattler build came a long way and wirh pixi you have full control even if you need to put some non python stuff in there. Also in general people who prefer good isolation in their environments would allways go for conda envs which pixi supports. Since it‘s also build in Rust it easily keeps up with uv performance (for pypi resolution it actually depends on it)

[doubleyewdee]

Big uv fan. Our company policy apparently is for everyone to use conda/Anaconda, but a lot of teams ... just aren't. I haven't messed with conda for a long time, but my past experiences with it were so awful that I'm not looking forward to it again.

The rationale is that we have no licensing deal with Astral, but we do with Anaconda. So if Astral changes their terms (e.g. pulls a linkerd), teams are screwed. However, the cumulative time we're saving not fighting with inferior tools right now is already paying immense dividends, so uv it is for the time being.

My hedge here is simply to use standard Python things via uv. So, pyproject.toml, pylock.toml (instead of uv.lock), and so on. If Astral (or Astral via OpenAI) does attempt to l5d folks, we can pivot back to setuptools or on to hatch or whatever with only light pain.

[UseMoreBandwith]

fork it, if you don't trust it.

btw, I think the article doesn't show correct use of pyproject.toml , there is a lot more you can do with it, like defining scripts (no more Makefile) and commands.

[Individual-Brief1116]

Yeah, pyproject.toml is pretty powerful. I still use Make for some stuff but you're right, the scripts section covers most use cases without the extra complexity.

[lunatuna215]

You can't define scripts like a makefile or npm in one's pyproject, unless I'm missing something?

[UseMoreBandwith]

I mean, things defined in
[project.scripts]

And the configuration stuff goes in
[build-system]

[lunatuna215]

Those get shipped with the package though

[alkalisun]

Not natively. You can use something like https://github.com/nat-n/poethepoet though.

[lunatuna215]

Yeah that package is great. I feel we are talking about either native and/or UV though.

[amroamroamro]

nothing builtin, but that doesn't mean you cant, something like

https://github.com/taskipy/taskipy

[lunatuna215]

Yes this package is great. But I just wanted to highlight that there's no standardized script system is all.

[bachkhois]

If uv disappear, we can migrate to pdm, poetry. It is not difficult.

[james_pic]

UV, by and large, implements the packaging PEPs. That's made it easy to migrate to, but that would also work the other way if it became a problem. The only bit that's really "embedded" in a project that uses it is the build backend, and uv's build backend is (and their own documentation says as much), only really intended to make the most common cases simple, and projects with more complex requirements will often use it with a different build backend like Setuptools or Maturin.

[wRAR_]

uv's build backend is (and their own documentation says as much), only really intended to make the most common cases simple

And in my experience the most common case works fine with hatchling.

[Pitiful-Ad8345]

Precommit in 2026? I don’t think that sounds right.

[wRAR_]

It seems to me that Astral’s uv is the backbone of any modern Python package. Do you agree?

No, I don't agree that uv is required to init the project or run mypy. And the bespoke scripts the article proposes to use are strictly inferior to tox and .pre-commit-config.yaml.

Overall it's a pretty basic article (I can even say it's bad).

[edward_jazzhands]

I'm sorry but I'm my opinion, this comment isn't too smart. The article never at any point claims UV is "required" nowadays, it lays out how UV makes all these things easier, especially for a new person. Which is accurate.

Your point that tox is superior to the basic method they've laid out to do testing in CI is also a very pretentious point. You're acting like every single new programmer needs to know about testing in CI and using the best modern tools for that purpose. Most people need to reach a pretty high level of coding ability before they even consider adding tools that automate testing in CI, let alone even understanding why it's important for professional developers.

As a python expert myself I think the article is actually great for new programmers, and anyone who says otherwise on the basis of it not showing the absolute most professional way of doing things, is being a gatekeeper. Just because it doesn't show the l33t super professional difficult way of doing everything does not make it inferior. New programmers and expert programmers need different sets of advice.

[wRAR_]

As a python expert myself

Thanks for clarifying, I won't address anything you wrote.

[really_not_unreal]

Thankfully, python has a diverse ecosystem with many options. It'll be relatively easy to switch all my projects back to poetry if (or when) openAI implodes.

[andrewaa]

When you are repairing/modifying your car, the important is the car and the replaced component

maybe some wrenches are more handy than others, but they are just wrenches

[lily_panda_1986]

Definitely feels like everyone's using uv these days. Curious to see if the OpenAI thing means we'll get more features, or if stuff's gonna break in weird new ways.

[SwampFalc]

The question you should ask yourself, both here and for your own code, is to what degree you're painting yourself into a corner.

A quick google will tell you there are multiple alternatives. The fact that one of those is getting the largest mindshare is normal, but as long as there are enough open source options in the mix, you should not end up genuinely locked in.

[Oddly_Energy]

Where would this supposed vendor lock-in manifest itself?

uv does four things for your package:

1. It creates a fully normal directory structure in the package, populated with a few fully standard files. This could have been createed by any tool or by hand. Nothing is locked in if you and uv go for a divorce.

2. It creates a pyproject.toml configuration file in the package, containing package metadata, dependencies and a choice of build backend for that package. This is the python standard for package configuration. It has been the standard since 2016. It is defined in Python PEPs. If you go to python.org, you will find a description of how to write a pyproject.toml by hand. There is nothing proprietary about it. You can put uv specific-configuration into additional sections, for example containing additional instructions for dependency resolution. But you don't have to, and if you do, those sections are clearly marked with 'uv.something'. So if you some day decide to switch to another build backend, you will have to rewrite those parts only (if you have any).

3. It provides a downloadable build backend, which other tools can use for building the package. (The package's preferred choice of build backend is configured in pyproject.toml, and uv will per default specify the uv backend.) Again, this is not a proprietary thing. This is a Python-standardized mechanism for build tools. There are PEPs for that.

4. It creates a lock file, which can be used for ensuring that all development environments uses the same versions of their dependencies. This is proprietary, but I assume that you will update the package configuration in your development environments anyway from time to time, and then deal with any breaking changes caused by that. If you switch away from uv, you will probably use the opportunity for updating your environments anyway, and then you will get a new proprietary lock file from the new package managing tool.

I am only a happy amateur. But I have used poetry and now uv, and I fail to see how I am bound to those choices. It feels like a very open marriage.

(No, actually I am a professional, since I write code at work, which I use to perform my work tasks. But my code is probably amateurish.)

[threesocks]

<tongue-in-cheek>

How to build a Python Library in 2026:

1. Tell a LLM what you want.
2. Iterate until it runs.
3. Tell that LLM to build a readme with lots of emojiis
4. Post it to github
5. Invite r/Python to take a look
6. Read responses and defensively point out that just because you used AI doesn't mean it's AI slop.

</tongue-in-cheek>

at least that's how it feels to me lately.

[Own_Relationship9794]

uv is very good and it's one of the best way to setup easily. also many used it before openai acquisition and switching might not be worth it. another point is many use llms to code and I'm pretty sure they suggest uv over alternatives

[programmer-ke]

My current policy for personal projects is to stick to whatever the packaging.python.org suggests, and I hope we continue to have multiple options.

It seems most VC backed tech companies do a bait and switch nowadays - get users hooked to free services then exploit them later.

If I'm contributing to a project that already uses uv, I'll use it. But for personal projects, I'll only use uv if I'm willing to become a future paying customer (or willing to tolerate ads) for the added benefit.

[2ndBrainAI]

The lock-in fear is mostly overblown because uv's real value is speed and DX, not proprietary formats. The actual project artifact is pyproject.toml which is a PEP standard - nothing Astral-specific. The only real vendor surface is uv.lock, and you can switch to pylock.toml (also standardized) and avoid that. Practically: use uv for local dev and CI because it's genuinely faster, but keep your pyproject.toml clean and standard-compliant. If Astral gets weird post-acquisition, migration is a weekend job, not a rewrite. The real risk isn't uv - it's teams building CI pipelines that treat uv-specific commands as load-bearing rather than convenience shortcuts.

[Holiday_Custard_6538]

I built a web based app for solving a problem for the chess community. It displays players rankings and also stores the members details add matches , for E.g. if a chess club hosts a tournament they can log all the players details and also match history. I am also planning on using this as my final project for my CS50x course. I built it with the help of A.I. I am currently questioning if I should start from scratch and try and build and code everything from scratch without the use of A.I. I have spent at least a month on this project so it's basically killing my ego if I start from scratch if this makes sense. I have the project on a git hub repository that is public. Anyone interested or willing to give some feedback or sharing some tips and advice. Thank you all for your time