Update to pydantic 2

[squidarth]

Why Pydantic 2?

Pydantic 1 -> 2 upgrade has some serious breaking changes, that have been a big pain for a lot of OSS developers.

The main motivating factor for us updating the version now is that we are going to start using more Pydantic stuff in Truss (particularly around the TrussConfig). We don't want to have to do a migration at some point, so now feels like a good time to make this change.

As a sidenote -- we are already getting complaints from customers that they cannot install truss because it currently depends on pydantic 1.

Impact

It's possible that this will create a new set of customers that cannot install Truss from pypi, which is my biggest worry here. I think there are two main mitigations:

1. In the immediate-term, we can push people to make a virtualenv to run truss, so that it doesn't impact other python dependencies
2. In the medium-term, we should move away from a pip install for truss, since it isn't really a Python library (CLI is the main interface now), and instead have it be brew installed primarily.

Alternatives

Supporting both versions of Pydantic

This is a lot of work for us right now for what we are doing.

Notes on implementation

Note that in this branch I don't touch the versions for truss-server or the control-server. The main thing that this impacts is the context builder (and of course, the CLI). Those changes we'll do in a follow-up. It's complicated, because to update fastapi on the control server, we need to have a Truss release first! (the control server depends on Truss).

Testing

I tested building a model on dev, and it seemed to work.

Supporting

[amiruci]

i've been reading some stories like this. just a heads up
https://twitter.com/jeremyphoward/status/1703112053446385915

[squidarth]

i've been reading some stories like this. just a heads up
https://twitter.com/jeremyphoward/status/1703112053446385915

@amiruci eThanks for the heads up -- I think as long as it works for our project, i think it's fine. Truss will be becoming just a CLI (and installed via brew), and so I'm not as worried about conflicts with other libs people have installed

[bolasim]

I don't think it makes sense to bump the versions in pyproject.toml which sets the packages we're using for unit tests, without bumping the versions inside the truss server itself (we'll be testing code in unit tests that's different from what actually gets run). Secondly, this doesn't eliminate the problem of people install pydantic2 in their truss to use for input/output typing.

[squidarth]

I don't think it makes sense to bump the versions in pyproject.toml which sets the packages we're using for unit tests, without bumping the versions inside the truss server itself (we'll be testing code in unit tests that's different from what actually gets run). Secondly, this doesn't eliminate the problem of people install pydantic2 in their truss to use for input/output typing.

That's fair. How about this -- to solve the circular dependency w/ the control server, I can do the following:

• Make an RC with the changes in this PR
• Update the truss version in control server to that RC
• Test this carefully
• Then after merging this PR, update the truss version in control server requirements to the new proper release

[squidarth]

Dropping this in favor of this plan: https://www.notion.so/ml-infra/Use-of-pydantic-in-Truss-7b76357bf39d47efa11cdb5212eb6ca8?pvs=4