Context
The assigned developers (among others) have been meeting during the Spring 2021 PCW to discuss a Pyresample 2.0. This issue discusses one of the changes that we think should be implemented on our road to version 2.0. Most features for version 2.0 will be backwards compatible and will not require a deprecation cycle.
For related issues, see the other issues in the v2.0 milestone (see sidebar).
Proposal
To make it easier for users to refer to resampler classes we should refer to them by name and allow users to request them by name. See #357 for how they should be loaded. For registering the Resampler classes we need a registry to store them and a way to register the classes in that registry.
The registry will likely just be a global dictionary in a pyresample module with access given to it by the create_resampler method for reading and register_resampler (see below) for writing to it.
Registration 1: Runtime
from pyresample import register_resampler
register_resampler('some_name', some_class)
Registration 2: On import
This would likely be used by internal resamplers as well as any package that wants on-import registering of their resamplers.
from pyresample.resamplers import BaseResampler
from pyresample import register_resampler
@register_resampler('some_name')
class MyResamplerClass(BaseResampler):
...
Registration 3: Entry Points
Setuptools (setup.py) allow for entry points to be defined. This way when a package is installed that defines these entry points, pyresample will automatically pick up on them without the user needing to explicitly import the package.
setuptools.setup(
...,
entry_points={
"pyresample.resamplers": ["some_name=mypkg.some_module:MyResamplerClass"],
},
)
This can also be done in setup.cfg as an alternative:
[options.entry_points]
pyresample.resamplers =
some_name = mypkg.some_module:MyResamplerClass
As long as create_resampler is written to check for the entry points then this should all "just work".
Context
The assigned developers (among others) have been meeting during the Spring 2021 PCW to discuss a Pyresample 2.0. This issue discusses one of the changes that we think should be implemented on our road to version 2.0. Most features for version 2.0 will be backwards compatible and will not require a deprecation cycle.
For related issues, see the other issues in the v2.0 milestone (see sidebar).
Proposal
To make it easier for users to refer to resampler classes we should refer to them by name and allow users to request them by name. See #357 for how they should be loaded. For registering the Resampler classes we need a registry to store them and a way to register the classes in that registry.
The registry will likely just be a global dictionary in a pyresample module with access given to it by the
create_resamplermethod for reading andregister_resampler(see below) for writing to it.Registration 1: Runtime
Registration 2: On import
This would likely be used by internal resamplers as well as any package that wants on-import registering of their resamplers.
Registration 3: Entry Points
Setuptools (setup.py) allow for entry points to be defined. This way when a package is installed that defines these entry points, pyresample will automatically pick up on them without the user needing to explicitly import the package.
This can also be done in setup.cfg as an alternative:
As long as
create_resampleris written to check for the entry points then this should all "just work".