Use v1 and v2 in parallel?

[chbndrhnns]

I am wondering whether (and if yes, how) it will be possible to install both versions of pydantic in parallel?
For bigger projects, I see this as beneficial to be able to migrate certain parts step by step without the need for a big bang migration.

[caniko]

It is impossible to install two separate versions of the same package in one environment; maybe possible with some dirty tricks (make a 2nd package with the old version). This seems more like a deployment issue, and not pydantic-related 🤔

Have you heard about blue & green deployments? Example by RedHat. You can keep one of the deployments in the old version for production, and migrate at your own pace on the dev deployment.

Migrating to v2 should be painless in most cases, but don't take my word for it.

[caniko]

I really do think the right way to go is some intelligent deployment, simplest being blue/green. If you want my advice: Get some insight into deployment before treading down this path, and avoid bad habbits.

I am not sure I understand the model argument, could you be more specific? Are you, perhaps, concerned that your openapi schema might be different for the two deployments? I am not sure that this is an issue, but rather something that needs to be adapted towards in the dev deployment. This issue is unavoidable nonetheless, no matter the migration path.

Why would you ever overwrite pydantic methods or force unsupported behaviour in production? The furthest I would ever go is class Config. Assuming these are MINOR or PATCH: Please make suggestions/PR upstream; yes it will take time, IMHO it is worth it. Either you will get some feedback, or the community and maintainers will upgrade the available features.

[chbndrhnns]

#1696 contains one example where a workaround came up in an issue. It's no longer relevant as it has been implemented but these are the kind of workarounds.

[caniko]

So the example for the argument is irrelevant?

[chbndrhnns]

Get some insight into deployment before treading down this path, and avoid bad habbits.

I often try to migrate code in small steps which involves duplicating existing code, implementing the new functionality there, then switch to the new implementation.
Would you help me understand what bad habits you see in my approach?

[caniko]

I don't see any bad habbits, it was just general advice.

Infrastructure should be designed in a way that allows you to deploy smoothely, and develop safely. Right now, it seems your infratructure is unsafe because you are asking for a cringe/niche feature; now if you are in one of these cringe situations, please, by all means, disregard the advice.

Migrating in small steps is an unnescessary addition of complexity unless it is several story points (big project). Most of the time, you want to create a dev branch, and migrate your codebase to the new version―no intermediates.

Happy coding 🛩️

[samuelcolvin]

It's an interesting idea.

I can definitely see the advantage for big projects.

We could perhaps release a "pydantic-next" package to support this, but only if there's enough demand.

[caniko]

I just hope this doesn't become a norm in production, but rather a tool for developers for migration purposes. This should only be used in some cringe/niche cases only.

[samuelcolvin]

agreed, but in a big project where you have hundreds of models, i see where it could help.

Instead of pydantic_next, it might be better to flip it around and have pydantic_old to be explicit to encourage newer pydantic to be the default.

[caniko]

agism, I like it @samuelcolvin 😆

[tlambert03]

I like pydantic_old as well ... see related discussion: #5402

this would allow a library to protect itself from ending up in an environment with another library that has gone through the upgrade and pinned itself to pydantic>=2.0. (Otherwise, an ecosystem of libraries that might be used together needs to essentially synchronize their updates)

import pydantic_old as v1

class Model(v1.BaseModel):
    ...

[Bewinxed]

This would be fantastic as in my case the other libraries that depended on pydantic immediately broke (fastapi for example)

[samuelcolvin]

This should be solved by #5771

[jolynch]

Just want to tag in the issue #6523 where I think I am echoing a lot of @tlambert03 's points, and surfacing real pain that is happening now that this has been released.

There is a silver bullet to this problem, just rename your package when you break the API and everything just works. If you want folks who pip install pydantic to get the latest major version that's fine, you can still release the latest version as pydantic (this is what elasticsearch-py does), that doesn't stop you from releasing the v1 branch as pydantic1 and libraries can pin to that to cohabitate. To do the simultaneous publish, imports have to be relative, but looking at this specific project only a few imports would have to be converted - I could take a try at it if @samuelcolvin indicates openness to this technique.

If you want folks to upgrade and not stay pinned down forever, releasing the separate package names is the best way to do that as it allows libraries and applications to make independent choices.

[tlambert03]

yeah, it's a sticky/tricky situation. #5771 offers a bit of a salve, It's not quite as clean as a pydantic2 namespace (though I can definitely understand why the authors were hesitant to lose the "pydantic" namespace)... anyway, since v1 is bundled in with pydantic, you can

try:
    from pydantic import v1 as pydantic
except ImportError:
    import pydantic

of course, that requires you to update all of your stuff, but it will at least protect you from finding yourself in an environment with pydantic2.

[jolynch]

though I can definitely understand why the authors were hesitant to lose the "pydantic" namespace

They can do both, they can still release to pydantic while also releasing to pydantic1 and pydantic2, the library just has to use branch based development for old versions (seems to be the case already) and relative imports (should be a simple patch).

[maartenbreddels]

try:
    from pydantic import v1 as pydantic
except ImportError:
    import pydantic

It would have been nice if this was in the migration guide. Due to the split off of pydantic-settings into a separate package we could not support both v1 and v2, and had to fully take out pydantic. If we knew this we could probably used that.

see widgetti/solara#189 and #6497

[caniko]

Pity, I think with careful planning and migration, your users would be just fine. FastAPI is a fine example on how to migrate your users from v1 to v2.

Cheers