Post AdgDPfi28olnD7UDg0 by Volker@fosstodon.org
(DIR) More posts by Volker@fosstodon.org
(DIR) Post #Adg3bGPh17wOgrnRbM by simon@fedi.simonwillison.net
2024-01-09T18:11:15Z
0 likes, 0 repeats
Given how Pydantic 2 broke compatibility with Pydantic 1 in a way that's still shaking out - you can't use 2 in a project that has dependencies that use 1 without making changes to those dependencies...... I wonder what the downsides of releasing Pydantic 2 as a new package called "pydantic2" such that it could be installed in the same namespace as the original pedantic would have been?Presumably this is how Jinja ended up as "jinja2" forever?
(DIR) Post #Adg46FdxvfmZHQFT3A by floby@mastodon.social
2024-01-09T18:16:18Z
0 likes, 0 repeats
@simon given how dependencies are expected to be resolved in pip/poetry/virtualenv, then yes, this is only proper way to increment the major of a semver in python.Dependencies are resolved this way because the pYtHoNiC way is to disregard depency injection and consider the module loading system to be the way to get singletons. This is also the reason why our tests are riddled with mock.patch shenanigans.
(DIR) Post #Adg4emcDqZX5O0to4u by webology@mastodon.social
2024-01-09T18:22:53Z
0 likes, 0 repeats
@simon It might be easier to do the opposite. Create a pydantic1 package which either re-namespaces everything, or that pins to `pydantic<2`. The first solution might give you some `from pydantic1 import pydantic` to work with.
(DIR) Post #Adg4xjtYBaYeS12jia by ianthetechie@fosstodon.org
2024-01-09T18:26:15Z
0 likes, 0 repeats
@simon hmm… I think the way Pydantic gets used is slightly different than Jinja, but that’s an interesting theory. It could also have to do with the only 1.x not being compatible with Python 3. Alas, now we have a Jinja2 version 3.something 😂
(DIR) Post #Adg5zOGhfDipuWDweG by hynek@mastodon.social
2024-01-09T18:37:46Z
0 likes, 0 repeats
@simon In the end it’s literally the Go approach, except that in Go the version is usually an extra path and not part of the name – but the effect is the same.
(DIR) Post #Adg7tyABUiwBPJiYCW by Pashhur@mathstodon.xyz
2024-01-09T18:59:07Z
0 likes, 0 repeats
@simon I think both urllib3 and botocore updated to version 2.0 that wasn't compatible with 1.0, but users stopped complaining after a few months
(DIR) Post #Adg86y2FHXUwm6CajA by davidism@mas.to
2024-01-09T19:00:53Z
0 likes, 0 repeats
@simon Heads up, I'm changing back to "jinja" in 4.0 (with compat imports for a long time) because I'm tired of the jinja/jinja2 split 😉
(DIR) Post #AdgDPfi28olnD7UDg0 by Volker@fosstodon.org
2024-01-09T19:59:58Z
0 likes, 0 repeats
@simon that would have been sensible and it was suggested here https://github.com/pydantic/pydantic/discussions/5402 but rejected by the pydantic folks. Would have saved me a bunch of work.
(DIR) Post #AdgF8fPeBrrxHBuD32 by Miikka@mastodon.social
2024-01-09T20:20:06Z
0 likes, 0 repeats
@simon There's the minor downside that people who rely on automatic dependency updaters like Dependabot do not learn about the existence of the new version via that route
(DIR) Post #AdgJ7tqDSYkdYKDrWK by simon@fedi.simonwillison.net
2024-01-09T21:04:51Z
0 likes, 0 repeats
Via @Volker here's a lengthy conversation from April last year where the Pydantic team debated the merits of this kind of approach https://github.com/pydantic/pydantic/discussions/5402
(DIR) Post #Adgc5ymW1EnRQOI0fY by alys@selfy.army
2024-01-10T00:37:30Z
0 likes, 0 repeats
@simon honestly it seems like there are more social downsides than technical ones. it's not that popular of an approach so package users don't have expectations, and it's unclear how to communicate with users who aren't going out of their way to read release documentation.
(DIR) Post #Adhn5FGGAOxs811MVU by simon@fedi.simonwillison.net
2024-01-10T14:04:35Z
0 likes, 0 repeats
Interesting note from Joey Lynch in https://github.com/pydantic/pydantic/issues/6523"Netflix is a relatively small Python shop (mostly does Java), but at my previous company Yelp which had 10+ million lines of python, library authors were forbidden from breaking their public API without a package name change due to the hundreds of hours of work that go into upgrading when libraries break compatibility."
(DIR) Post #AdhnyH0HOHX5SVmmIq by pamelafox@fosstodon.org
2024-01-10T14:25:28Z
0 likes, 0 repeats
@simon also "The standard way in the python ecosystem to release a backwards incompatible library is to rename the package so the versions can cohabitate." ...is that standard? i get the reasoning, but it seems fairly rare.
(DIR) Post #AdhoLpsfsqYAI0Spmq by theaxer@floss.social
2024-01-10T14:29:29Z
0 likes, 0 repeats
@simon I find this situation fascinating. As someone that has done a lot of Go and Python development. It really looks a like a "damned if you do, damned if you don't situation". Go basically requires name changes by including the major version in the import path (for v2 and higher). But people generally complain about it. But here we have people asking for it.
(DIR) Post #AdhoYPFIDwVjRk2Oh6 by haliphax@hachyderm.io
2024-01-10T14:30:26Z
0 likes, 0 repeats
@simon I feel like semantic versioning solves this so long as it is *actually* used and not just paid lip service
(DIR) Post #Adhok9ee17M2ZBUvHU by wjt@mastodon.me.uk
2024-01-10T14:33:44Z
0 likes, 0 repeats
@simon libsoup (the C HTTP library for the GNOME stack) broke its public API and ABI while keeping many symbol names the same, causing absolute chaos because several foundational libraries were not updated for the new API while others were updated to only support the new API. A year later, several GNOME-adjacent projects e.g. Flatpak are now de-facto only usable when configured to use libcurl rather than libsoup, surely not the desired outcome!
(DIR) Post #AdhqwixWmUP1ReS3jE by jni@fosstodon.org
2024-01-10T13:20:57Z
0 likes, 0 repeats
@simon @Volker the whole thing has left me convinced that a rename is the only sane way to do such a thing. See also https://github.com/pydantic/pydantic/issues/6523 for some of the aftermath. 🍿😭
(DIR) Post #Adhrz8gyB4K3mtQEQS by iamkale@infosec.exchange
2024-01-10T15:10:16Z
0 likes, 0 repeats
@simon I wish I'd seen some of these conversations earlier. The complexity of maintaining a library that tries to support both v1 and v2 was too much for me and I recently announced that I'm removing Pydantic as a dependency. I wonder if things would really be better with v1 or v2 under a new package name...https://infosec.exchange/@iamkale/111705909842887194
(DIR) Post #Adi0Paol1rJOBEBphY by predrag@hachyderm.io
2024-01-10T16:44:34Z
0 likes, 0 repeats
@simon this is also a function of tooling:- It's hard to check for backward compatibility.- It's hard to upgrade many dependencies to a new library version.With better tooling, we wouldn't have to rename libraries like this.
(DIR) Post #Adi1NE0cxYV0odB0yW by simon@fedi.simonwillison.net
2024-01-10T16:55:32Z
0 likes, 0 repeats
@pamelafox yeah I found that very questionable - I've seen Jinja do it (once) and boto and nobody else
(DIR) Post #Adi1ZVgn3FOl7lkvqa by danyeaw@fosstodon.org
2024-01-10T14:34:50Z
0 likes, 0 repeats
@pamelafox @simon In addition to SemVer, CalVer, and ZeroVer, do we need a RenameVer?
(DIR) Post #Adi1ZXErI4FBviheaW by simon@fedi.simonwillison.net
2024-01-10T16:55:58Z
0 likes, 0 repeats
@danyeaw @pamelafox RenameVer is genuinely a great name for this pattern!
(DIR) Post #Adi1lXRgLaZc2wQOrw by simon@fedi.simonwillison.net
2024-01-10T16:57:19Z
0 likes, 0 repeats
@haliphax in this case semantic version is what caused this problem: it gave the Pydantic maintainers to break backwards compatibility between v1 and v2, but that causes havoc in the wider ecosystem of libraries that use Pydantic because they become incompatible with each other due to differing dependency versions
(DIR) Post #Adi1yweVwJbTzNosk4 by simon@fedi.simonwillison.net
2024-01-10T16:58:29Z
0 likes, 0 repeats
@iamkale I've been contemplating dropping Pydantic as a dependency for my LLM library for the same reason
(DIR) Post #Adi29tjH9FrW6mGlvs by predrag@hachyderm.io
2024-01-10T16:47:14Z
0 likes, 1 repeats
@simon on that note, I'm working on a Python linter that can find and report breaking changes between package versions!Like my Rust linter cargo-semver-checks, but for Python. Before making a new release (or merging a PR), run it to make sure no unintended breaking changes have snuck in.Who should I be talking to about this? Who needs to use it the most?#rustlang #python #semver
(DIR) Post #Adi29upL4CJ3Vs781Q by simon@fedi.simonwillison.net
2024-01-10T16:59:51Z
0 likes, 0 repeats
@predrag that sounds really useful! I'm not sure what the best place to get that in front of library maintainers is
(DIR) Post #Adi4HNbgf7ZGhvPosy by robinhouston@mathstodon.xyz
2024-01-10T17:27:57Z
0 likes, 0 repeats
@simon @pamelafox Psycopg? Though they've done it even more confusingly, because psycopg2 is the old version and paycopg is the new one.
(DIR) Post #Adi7F6apFSDBDtcTVg by predrag@hachyderm.io
2024-01-10T18:01:16Z
0 likes, 0 repeats
@simon lmk if you're open to trying it on the datasette ecosystem — that'd be a very solid start 😎
(DIR) Post #Adi8XOPxoZMbfkp5hQ by anandphilipc@sigmoid.social
2024-01-10T18:15:26Z
0 likes, 0 repeats
@simon @predrag did you guys see this https://sigmoid.social/deck/@jackerhack@mastodon.social/111628908483614449 on type checkers, tangentially related.