gplately.pygplates.FeatureCollection is broken

[michaelchin]

          Hi @michaelchin, 

Maybe we can modify and incorporate this unit test file in the automated Pytest cases.

You should absolutely add these tests to the automated testing. Is there any reason why all these tests are not run automatically using CI?

The reason that the features were not pickled might be because the setstate and getstate functions were not implemented.

I'm just using pygplates.FeatureCollection at this stage.
There are still problems:

1. It looks like filenames has become a global variable, appending multiple filenames from other FeatureCollections. Execute the same cell and the filenames are appended again.
2. The FeatureCollection is not properly loaded when you specify the filename using the filenames keyword. In my example above, if you set gplot.time=0 and access the gplot.COBs attribute, you get a None.

As far as I can tell this object is completely broken. You should build and example on your machine and test a fix for this thoroughly. I say this because all of the workflows which make use of multiprocessing rely on this working. This is high priority stuff!

Originally posted by @brmather in #186 (comment)

[michaelchin]

I tried to roll back my changes, but, unfortunately, found the FeatureCollection class was even in worse condition before my code changes. Since the class is very simple and straightforward, I think we should fix it instead of rolling back to a much worse version.

[michaelchin]

I rolled back FeatureCollection class code changes to 2d6a98d. All my recent changes on FeatureCollection class have been dropped. Since the new pygplates will come out soon, the gplately/pygplates.py will be removed after the new pygplates release. We should not waste too much time on the FeatureCollection class.

@brmather let me know if the rollback has fixed your problems. Thanks.

[michaelchin]

I tried to roll back my changes, but, unfortunately, found the FeatureCollection class was even in worse condition before my code changes. Since the class is very simple and straightforward, I think we should fix it instead of rolling back to a much worse version.

No, we should not waster time to fix the new code. Simply roll back the code changes and wait for new pygplates release to get rid of pygplates.py.

[michaelchin]

Rollback has been completed in 2d6a98d and 25c75cd. I will close this issue in 7 days if no further problems are reported. Unpin this issue and downgrade the priority to 'medium'.

[michaelchin]

pending close

[michaelchin]

wait until 10 July, 2024 for Ben's return

[brmather]

This is working correctly for me now, but I wonder if we should keep this open until we test the notebooks / John releases the next version of pyGPlates with parallel support...?

[michaelchin]

This is working correctly for me now, but I wonder if we should keep this open until we test the notebooks / John releases the next version of pyGPlates with parallel support...?

Testing the notebooks will be tracked in new issue #223