fix: ReferenceMixin._ref weakrefs after deep copy

[tlambert03]

fixes #265

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.95%. Comparing base (a17bf57) to head (40b7b6c).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #272      +/-   ##
==========================================
+ Coverage   86.85%   86.95%   +0.10%     
==========================================
  Files          25       25              
  Lines        1263     1273      +10     
==========================================
+ Hits         1097     1107      +10     
  Misses        166      166              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

CodSpeed Performance Report

Merging #272 will not alter performance

_{Comparing fix-265 (40b7b6c) with main (a17bf57)}

Summary

✅ 9 untouched benchmarks

[tlambert03]

@erickmartins, heads up: this PR is going to break omero-cli-transfer. specifically it looks like you were "locally fixing" this bug in omero-cli-transfer by calling newplate.annotation_refs.remove(annref) in create_plate_map here: https://github.com/ome/omero-cli-transfer/blob/360b535ec2a5d301388417d8bc84b8788250c1e2/src/generate_omero_objects.py#L339

unfortunately, using .remove() essentially requires that the reference is present in the list... it never should have been in the first place, and now that we also found this issue, we're fixing it here.

you can see how our test of omero-cli-transfer is now failing here:
https://github.com/tlambert03/ome-types/actions/runs/12576599869/job/35052927242?pr=272

I'm afraid you'll have to either do some ome-types version specific logic now, use a try/catch, or check for the presence of that reference before trying to remove it.

[erickmartins]

Appreciate the heads up! I'm about to go on vacation and might not have time to dig into this before then, but will do as soon as I'm back.

[tlambert03]

ok, this is working now, but only for pydantic v2. I actually think that deepcopy with pydantic v1 may have had some subtle untested broken issues with already, that this is exposing. I'm skipping that test for now, and will probably just drop support for pydantic v1 altogether in another PR. it's been out for 1.5 years, plenty of time for libraries to update just enough to use the pydantic.v1 import if they want