Make API consistent across backends

[Apreche]

The point of using a library like django-storages is to abstract away the difference between the cloud object storage solutions. The same code should execute the same tasks across the different backends without the developer having to worry about which backend is in use. django-storages does not hold up to this principle, because the API is not consistent across the different backends.

Here is a simple example:

from storages.backends.gcloud import GoogleCloudStorage
from storages.backends.s3 import S3Storage
backends = [
    GoogleCloudStorage(**credentials_and_config),
    S3Storage(**credentials_and_config),
]
for backend in backends:
    print backend.url(foo, expire=3600)

This code doesn't work. Why? Because S3 supports passing the expire parameter to the url method, but Google does not.

I'm just using the url function as an example. Ideally all the backends will have the same public methods with the same signatures. Then the same code can work regardless of which backend is being used. As the library is now, developers will have to write code such as if azure:... to account for these differences, and it somewhat defeats the purpose.

[dimbleby]

The API is Storage https://github.com/django/django/blob/2debd018dbc7aba0b98b4c082bbb1fa1d195a47e/django/core/files/storage/base.py#L11

if the S3 implementation disagrees with the base class, that is a bug

[jschneier]

@dimbleby I do not agree. I think it's fair to say that all of the django-storages backends should present a consistent API, probably of def url(self, name, **kwargs) but implementing support for each backend isn't work I am going to personally undertake.

Most likely the Django API should be similarly extended but I don't think it makes sense to restrict the functionality so harshly here.

[dimbleby]

If classes inherit from Storage but disagree with it where it defines an API, - that is a bug (as I expect any typechecking tool should agree).

I agree that this could be resolved either in the parent or the child (or both).

Providing additional inheritance / mixin methods that do not contradict the base class is also fine.

[jschneier]

If we put aside typechecking then the Django-Storages classes do conform to the API. All additional args are kwargs with default values.

[dimbleby]

Yeah but different backends taking different kwargs is pretty much exactly what OP is complaining about!

[jschneier]

Okay so it’s not a bug due to Django but within-library compat.

Should just have the API extended to take kwargs and forget about this.

Will open a feature request with Django and also can make this consistent here.