Skip to content
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

Optional dependency for different storages? #709

Open
huxuan opened this issue Jun 24, 2024 · 2 comments
Open

Optional dependency for different storages? #709

huxuan opened this issue Jun 24, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@huxuan
Copy link
Contributor

huxuan commented Jun 24, 2024

🚀 Feature Request

Although we support many kinds of storages, actually we only use one kind of them. So it would be great if we have different storages as different groups of optional dependencies. I have to admit this will bring back-compatibility issue. Just a head up here whether this could be possible to happen.

Motivation

We are migrating our code base from stratch and finding that streaming dataset introduces a lot of dependencies that we will not likely to use in the near future.

[Optional] Implementation

Additional context

@huxuan huxuan added the enhancement New feature or request label Jun 24, 2024
@snarayan21
Copy link
Collaborator

snarayan21 commented Jun 24, 2024

Hey @huxuan, could you please clarify which dependencies you need and not need? Right now we have the large cloud providers as required dependencies (AWS, GCP, Azure, OCI) and other providers as optional (Databricks, Alipan, etc.)

@huxuan
Copy link
Contributor Author

huxuan commented Jun 24, 2024

Hey @huxuan, could you please clarify which dependencies you need and not need? Right now we have the large cloud providers as required dependencies (AWS, GCP, Azure, OCI) and other providers as optional (Databricks, Alipan, etc.)

Thanks for the reply, actually we only use s3 compatible storage, so I suppose we only need boto3. A general idea is to have all the providers as optional. Maybe another approach is to provide a package only with the core functionalities and name it as something like streaming–core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants