-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make built-in adapters' identifiers configurable #247
base: master
Are you sure you want to change the base?
Make built-in adapters' identifiers configurable #247
Conversation
b53f171
to
24f57ef
Compare
82fb415
to
80cbb9d
Compare
@phiresky This is ready for your review whenever you get the chance. |
@phiresky Bumping the request for review. |
In general this seems like probably a good idea, but I'm not sure about the approach?
Maybe it would be better and simpler to use a syntax like As in, you specify pairs of extensions [a,b] and every file with extension a is treated as if it had extension b. That way you also don't the additional mapping of how the adapter should treat the file internally (only relevant for the The only change that would be needed is that the "fake" extension needs to be given to the adapter. Since some files given to an adapter already don't actually exist on the FS (e.g. within zips), this can potentially be done by just changing /// file path. May not be an actual file on the file system (e.g. in an archive). Used for matching file extensions.
pub filepath_hint: PathBuf, Then no other changes are required per adapter, and the override also works to temporarily override extensions of custom adapters a user has configured. |
Going the complete other way: This problem seems to really only have appeared for But probably the general solution above is better |
800cb6d
to
9b45e19
Compare
This will allow end users to provide their own lists of extensions and/or mimetypes for each of the built-in adapters.
9b45e19
to
982b233
Compare
This will allow end users to provide their own lists of extensions and/or mimetypes for each of the built-in adapters.
This feature would obsolete the need for feature requests such as:
.als
file support #185The functionality proposed here is a superset of that in #244. That PR makes only the Zip adapter's extensions configurable, whereas this exposes the extensions and mimetypes of all built-in adapters for end-user configurability.
Output of
cargo run --bin=rga -- --rga-print-config-schema
from this branch.