Read importlib.metadata to find transport / compressor extensions #697
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Title
Read importlib.metadata to find transport / compressor extensions.
Motivation
For now, if user install a package that provide new
smart_open
transport mechanism, it cannot be automatically registered.It would be great if
smart_open
could be extended using setuptools / entry_points capabilities.Example use case
Please note: schema is not relevant here.
In package
smart_ext_transport
I have following file:Current situation
The only way to load extension for now are listed bellow:
Option 1: using
register_transport
everywhere and every time it might be required 😢Option 2: using
__init__.py
andimport
statement:Adding:
Then every time
custom
schema might be needed:Improved situation with setuptools
In
setup.py
fromsmart_ext_transport
we may add:Once package is installed,
smart_open
can automatically load every plugin that is registered using setuptools entry points.User will no longer have to import package to register extension manually.
This is how pytest / setuptools CLI / flake8 / jupyter nb convert works for example.
Handling correct version of
importlib.metadata
is mainly inspired frompytest
codebase.See my issue about this PR: #691
What it may change for the future ?
Future extension to
smart_open
may be moved out of core library.Example use case may be new extensions libraries like:
smart_open_zstd
to addzstandard
compresssmart_open_xxx_cloud
to add new cloud provider without having to implementing it in core library (like AliCloud).Core library will only have to maintain base / robust API and no longer have to support all possible URI provider / compression standard.
Checklist
Before you create the PR, please make sure you have: