Potentially confusing name?

[thibaudcolas]

Raised during team meeting – as I understand this is named as an analogy to django-storages, which supports multiple storage backends (popular cloud providers), while this project currently only supports S3.

A way to address this would be to simply rename the project. But if the general goal is to support more storage backends if possible, the existing name could work, just adding documentation to the README to explain the current support?

Something along the lines of,

## Supported storage providers

We currently only support AWS S3, as it has granular access control capabilities with ACLs. For other cloud providers,

- Azure has <limitations>, but they might be overcome.
- <other provider> has <more limitations>, and would not be currently usable

If you’re interested in contributing support for any of those providers, please open an issue to discuss implementation plans

---

If the confusion is a big issue it might also be worth updating the package’s description metadata to be suffixed with "– currently S3 only", or name drop S3 elsewhere in it.

[olifante]

Hi Thibaud, I see you mentioned that "Azure has limitations, but they might be overcome". From what I can see, Azure Blob Storage only supports ACLs at the container level, not for individual files. It seems like Azure Data Lake Storage Gen2 has ACLS for individual files and can be seen as a superset of ABS, but django-storages doesn't explicitly support ADLS2. What do you think is the best way to overcome the Azure limitations and add it as a supported storage backend for wagtail-storages?

[thibaudcolas]

@olifante 👋 I think my colleague @tm-kn is the mastermind here. I’ve only worked with Azure’s blob storage once myself, and have never looked into ADLS2. The limitation I mentioned back then I’m pretty sure was indeed the lack of ACL per object.