Dependency versioning

[JayThomason]

I would like to try using deltacat to replace using ray data with read_parquet and write_parquet on S3.

Unfortunately I cannot try deltacat with some of my team's most important datasets because there is a backwards incompatibility in ray 2.49+ which prevents reading tensor columns with older versions of ray.

Right now deltacat pins most of its dependencies to specific versions, for example ray is pinned to 2.46.0, a ~7 month old release.

It would be easier to use deltacat if it provided a wider range of compatible dependency versions for each release, e.g. ray>=2.X.0 or similar.

Is there a reason all of the dependency versions have to be pinned like this or would this be a viable change?

[pdames]

The dependencies have conventionally been pinned to support more deterministic/reproducible behavior and to reduce installation time (due to a previously exhaustive search for compatible dependency versions), but I think we can explore some selective loosening of pinned requirements starting with Ray.

We have also been actively working to eliminate many prior sources of dependency conflicts (e.g., between boto3 and s3fs), and create a more lightweight transitive dependency graph overall, so this may be a good time to pursue this work. Feel free to submit a PR for this change @JayThomason.

I'm also curious about overall appetite to add uv package management support to DeltaCAT.

[JayThomason]

I'm a pretty big fan of uv. I will take a stab at migrating to it and open a PR once it is working. It should make these sorts of changes easier in general.