OceananiganPythonInterface or ClimaOceanPythonInterface auxiliary package for collecting PythonCall utilities?

[glwagner]

Right now ClimaOcean defines an extension for PythonCall which allows one to use the copernicusmarine python package:

https://github.com/CliMA/ClimaOcean.jl/blob/main/ext/ClimaOceanPythonCallExt.jl

As discussed over on Oceananigans PR CliMA/Oceananigans.jl#4782 with @cjdoris and @vchuravy, it makes more sense to wrap this function in a new package (CopernicusMarine.jl?) which provides a wrapper around the python package copernicusmarine.

Then, ClimaOcean will have an extension ClimaOceanCopernicusMarine which hooks into the Julia package to define datasets / extend Metadata for CopernicusMarine.jl.

also cc @giordano

[glwagner]

Possibly we want to write a single wrapper package for all python packages that we want to use to interface with ClimaOcean (this will lower the bar for adding python capabilities to ClimaOcean). Discussed here:

CliMA/Oceananigans.jl#4782 (comment)

[cjdoris]

Having a single package for all the python integrations seems like a reasonable compromise. You can always split them out later if necessary.

[navidcy]

related: https://github.com/NumericalEarth/CopernicusMarine.jl

[simone-silvestri]

I will reopen this issue to discuss the fate of other Python packages we want to use.
In particular, #602 requires Python to download and interact with Veros. Shall we put this in another package? However, methods in #602 are tightly integrated with ClimaOcean (for example, the set!(::VerosSimulation, args..) method) to justify keeping this extension in ClimaOcean.
What do people think?

[glwagner]

You could consider a new package called OceananigansPythonInterface.jl which collects a lot of PythonCall stuff.