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

Add libcloud import to library itself #16

Open
Niccolum opened this issue Nov 23, 2022 · 4 comments
Open

Add libcloud import to library itself #16

Niccolum opened this issue Nov 23, 2022 · 4 comments

Comments

@Niccolum
Copy link

As for me, it will be nice, if I import only sqlalchemy_file library to import providers.
Of course, it's only my wish :)

For example, fastapi do it with starlette
https://github.com/tiangolo/fastapi/blob/master/fastapi/requests.py

@Niccolum Niccolum changed the title Add libcloud import to library Add libcloud import to library itself Nov 23, 2022
@jowilf
Copy link
Owner

jowilf commented Nov 25, 2022

Hello @Niccolum,
Thank you for your suggestion,
I think it's a good idea
It will be great to import both libcloud.storage.types.Provider and libcloud.storage.providers.get_driver from sqlalchemy_file

@hasansezertasan
Copy link

So what @Niccolum proposes is this right?

- from libcloud.storage.drivers.local import LocalStorageDriver
+ from sqlalchemy_file.drivers import LocalStorageDriver

or...

- from libcloud.storage.drivers.local import LocalStorageDriver
+ from sqlalchemy_file import LocalStorageDriver

If that's the case, I highly recommend using this pattern...

- from libcloud.storage.drivers.local import LocalStorageDriver
+ from sqlalchemy_file.storage.drivers.local import LocalStorageDriver

In case, if the user decides to import providers from the libcloud package, only one keyword/name change will be enough.

@Niccolum
Copy link
Author

Niccolum commented Jan 8, 2024

@hasansezertasan as for me, first or latest example are cool. But first is better, because we don't need to repeat the structure of another package, which can change in future

@hasansezertasan
Copy link

@hasansezertasan as for me, first or latest example are cool. But first is better, because we don't need to repeat the structure of another package, which can change in future

It's not just "another package", sqlalchemy_file is almost built on top libcloud. Learning libcloud is probably a great gain for the users. I believe we should respect their structure.

So I vote for the latest example... It's the author's choice after all 🙏.

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

No branches or pull requests

3 participants