Sick, I have a project where 80% of build time is on psycopg. It really doesn't make sense to rebuild it every time. If it's easy to set up a shared registry, we could even use it during development.
Also, installing packages according to the presence of GPU hardware has always been a pain. We've been dependent on tools like conda and more recently pixi. Maybe pyx can alleviate that too, we'll see.
For SQLModel users, lets throw some well deserved shade at tiangolo.
Is typer what tiangolo has been working on while not maintaining sqlmodel.
Will he stop maintaining typer as well?
typer under the hood is click. Which you are right click is better than argparse cuz it's optparse.
Left scratching my head, are you praising, click? What is your typer sales point over plain ol' click.
combining typer and click. Shows how to use click and/or typer to group sub-commands.
wake up, trio (and as a crutch anyio) is a thing. Making click and typer (and pathlib.Path) immediately legacy. No matter what it does. Here is the click trio port trio-click. Which i just checked, is actively maintained.
Where is the typer trio port?
which makes sense to me. params is passing the reference to the dict into the function. Whereas, **params is expanding the dict into the scope of the function before calling the first line of the body.
You can update the content of the former in-place, while the latter is just syntactic sugar for variadic function arguments.
Sorry, what is this really? I don't seem to encounter the problems mentioned in that blog post π§
I feel like a lot of the problems people encounter with Python are due to the non-Python dependencies that projects use and are mostly restricted to certain fields. My guess is that the people complaining are a mix of:
Hopefully the next blog post will walk through examples of "this is the problem people encounter with existing tools, this is what it looks like, this is how it looks like with our tools, this is how it works". The "how it works" could be split off into another blog post too.
Right now, this blog post just made me aware of pyx but that's about it.
Here is a bug fix where even a drug addict could see it's merge worthy.
Could fall off the bar stool semi-conscious and still be able to acknowledge it's merging worthy.
Just click the freak'n YES button.
Why market a package that is stuck in the WindowsXP era?
I don't think it's a good idea to use SQLModel in a serious project. It's not the best maintained because the only maintainer also maintains FastAPI, so SQLModel is sometimes left for quite a while without meaningful bugfixes.
I'd just use SQLAlchemy
Why single out lack of docs for foreign keys? The docs do deal with one to many and many to many relationships. Step by step.
The trick is finding that page. It's there, just TOC is wonky. Unnecessarily hard to find things.
Foreign keys howto is a minor issue compared to the 70 PRs in the waiting queue.
Production? SQLModel is not production ready. I can name 70 reasons why not.
Please SebastiΓ‘n bring on other maintainers with PR approval authority. Only this would be a game changer.
I just wish it was better documented for more complex use cases. Not everything is a handful of crud operations that fits within the same module/file.
Great package, though the documentation on foreign keys could be a bit better in my opinion
Typer and Pydantic are absolutely mandatory on any Python project I write. A million times better than argparse and dicts everywhere.
As much as I've been disliking fastapi's direction recently, I can't abandon its annotation-based dependency injection. Having to reference injection's parameter name twice, and potentially decoupled from the route itself, does not sound like a fun time. It especially gets complicated with nested dependencies. You have to eagerly determine all the dependencies of your dependencies and provide them to either the route decorator or the app itself.
I would much rather do this
@get("/")
async def index(injection: Annotated[str, Provide(getThing)]): ...
Than what is currently required
@get("/", dependencies={"injection": Provide(getThing)})
async def index(injection: Annotated[str, Dependency()]): ...
litestar#2990 has shown they have no interest in this feature.
Tell me about your experience. Would like to know how to avoid this trap.
I have next to no experience with managing open source projects :P
Probably most projects are as guilty as tiangolo. Myself included. How to scale to multiple maintainers? Tell me about your experience. Would like to know how to avoid this trap.
This seems to be a github weakness. Each of us individually contributes by making a great package. Folks start using it and situation does not scale.
Rinse wash repeat
Yeah, it's unmaintained because one guy, tiangolo, is the only maintainer for both of those projects, and he doesn't let anyone else approve PRs and so on. I think Litestar has a much better organisation structure.
If only would be so lucky. Truly i don't mind. Here go at
Purposefully do not have any code of conduct for any of my packages. And i have not joined python.org to avoid submitting to a code of conduct.
Everyone is welcome to be themselves. If something hurtful is said, i'll take it in stride without barraging the commenter with Captain obvious sweet nothings.
You troll, i disparage. It's not so different. Except for the two fresh super hero creation stories.
For the love of cosplay and super hero conventions, for a moment could put down those tunnel vision goggles to acknowledge the well written prose. Or not, but that's on you
Dear OP
SQLModel looks unmaintained. The PRs are languishing in purgatory waiting for the submitters to croak from old age. I died a little inside (see imdb all reviews must start with a drama queen comment like this) noticing the PR count has just achieved 70 PRs as of today. Which must be an achievement in project mismanagement.
According only from the release notes, the last real release was sqlmodel-0.0.23 on Feb 28th 2025. For those keeping score today is Aug 8th 2025
Most activity is bots upgrading gh actions and precommit autoupdate. aka commit spam.
The last human commit was Jun 19th fixing some tests for the docs.
This is a sell point for litestar. Bypassing pydantic also bypasses the horror show of SQLModel.
Will look into msgspec+litestar
Just my opinion of course: I wrote golang for years and wanted to love it for the first few. I like some of the patterns, but I got very tired of writing (and reviewing) boilerplate (or in the case of reviews, what should have been boilerplate but got missed). I know it has gotten a bit better in the past few years, but at this point I'd need a huge reason to leave python or look past rust.
Yep, I might give it a try in my next project, but I'm not completely sure if I'll use Go (with Gin) or Litestar and Python.
Currently giving it a try on a small API+async task project.
I think the hardest thing for me has been discovering which dependencies are (can be) injected and through what magic string. But, it's also easy to step through the source to find answers.
After many years of DIYing validation with Django, then attrs+flask, and then getting a lot of that work for free with pydantic+fastapi, msgspec+litestar feels like the natural evolution into a mature pattern.
The sqlalchemy models are first-class citizens, the service and repository classes just work (especially well if you use their advanced alchemy wrapper).
And the devs are very responsive (fixed a tiny bug I found in a weird corner with tests in a matter of hours).
I'm gushing a bit. So I'll just end it by saying I agree with the author: it's worth a look.
This isn't even close to chill, dude. Wow. If you think that tone is going to help, I'm not sure what going through your head. Would you welcome or be convinced by somebody writing like that in your open source project?
Nowhere was the term, idiot, uttered. It's not an issue IQ solves. If it's possible to just submit more PRs harder this situation would only worsen. No matter how many PRs or how well intentioned.
nuance is lost cuz the details keep piling up and its overwhelming. Have mercy! Provide a checklist. At the end of the checklist write This is everything you must do. There is nothing more. You are done!
You need to learn about humility
One more thing to add to the checklist. Is that sqlalchemy create_engine params, pass through dbapi drivers params, or sqlite peculiarities humility? And ask yourself if you want to be constantly thinking if only i was more humble create_engine would always work as expected, without worries, or in this case, without reframing (the conversation).
Are you seeing my point, the guy who points others to the contributing page?
The guy in charge of random database objects names does not harbor ill-intent, the heat he is packing in his pants is sufficient, he is in no way inadequate, in one way or another.
He's overwhelmed. And along the way, nuance is lost.
The guy in charge of random database objects names is legion. And if not him, someone and something else.
Hmmm seem to have misplaced that checklist, it's gotta be around here somewhere.
If you just want to quickly create a local python develop environment on the side using Python module metadata, installing uv from nixpkgs, and enabling nix-ld to run pre-compiled binaries from PyPI keeps things simple, and replicating the same virtual python environment workflow you to have on any other distribution:
https://discourse.nixos.org/t/i-want-understanding-nix-packages-and-flake-basics/67365/3
If you wanted to package a python module for nix or for proper distribution via nixpkgs, you'd want to add a nix derivation file that encapsulates all the inputs, i.e. software building materials (SBOM). There are existing nix library functions that can automate most of the packaging, not unlike Debian macros:
https://wiki.nixos.org/wiki/Python
The second approach is more rigorous, and combined with something like flakes for pinning the exact hash for all inputs via lock file ensures reproducibility, like when sharing with other nix users. While as the first approach is more subject to your current system, i.e. linking to whatever system wide libraries are presently installed, but it's less upfront effort to reuse existing python-package-managers than to nixify everything.
Bro, chill out. Just because someone missed something doesn't mean you have to lose your mind about it. Your comment could've been a helpful one that provides a solution and explains (in a calm and polite manner) why it could be better than what's proposed. Additionally, instead of complaining loudly about missing documentation and writing up a storm about it, why not contribute documentation?
Just because someone doesn't know something you don't, doesn't make them an idiot. You need to learn about humility.
btw my favorite super hero is the mustache guy from Deadpool. All time favorite.
Made a very convincing argument that what the super hero universes need is a guy with a thick mustache who just happened to show up for the interview with that stash.
That's what's been missing from every super hero team.
As far as i can tell the mustache guy seems like a good blook.
I hate good people with their good intentions, mustache guy didn't have good intentions. He just happened to want the job. Which was good enough for Deadpool.
This is why i'm nominating the guy in charge of random database object names to the team.
btw this is not off topic, read the SQLModel docs! All the examples are about super heroes and their teams. None of which i recognize cuz there also seems to be the guy who misspells super heroes and teams names
Which sorta makes sense. Anyone who'd lower case all table names would probably not be above misspelling super heroes and teams names.
Is there anything more sinister than lower casing all table names? And then ... get this ... preventing changing the table naming algo by hiding the implementation within a metaclass. Leaving the only option, to hardcode each and every table name.