Add support for a cache_url for Django

[epicserve]

I just switched to this library from https://github.com/joke2k/django-environ. One thing that it had was a way to set a cache_url for configuring Django's cache framework. It would be nice if you could just update the setup.py to install https://github.com/ghickman/django-cache-url, however it looks like it's deprecated.

[epicserve]

I also wonder if it would be worth moving dj-database-url, dj-email-url and a new django-cache-url into a repo like django-setting-urls or something?

[sloria]

I'm open to a PR adding cache_url support for Django.

[epicserve]

@sloria,

For clarification ... you're open to supporting the cache_url inside this codebase or just using another codebase. If the later, it seems like it might be good to consider bringing in all URLs (i.e. Database, Email, and Cache).

[sloria]

I'd strongly prefer to keep the cache url-parsing code outside of this package (as we do with database_url and email_url).

[epicserve]

@sloria,

I can certainly understand why you wouldn't want that code inside this repository, even though I really liked how django-environ had everything in its repository. So the way I see it, there are only a couple of options.

1. See if the owner of django-cache-url would resurrect their library so we could add it as a requirement for this one.
2. Create a new library that has the django-cache-url functionality.
3. Create a new library that has all the functionality of dj-database-url, dj-email-url and a new django-cache-url.

Out of all of those, I like 1 the best for me personally because it's the least amount of work and I wouldn't have to support it. I like 3 for its simplicity of only needing to include one library in this library. But I personally don't think I would have the time for a while to work on either 2 or 3 and the probably with all of these is finding a solution that will work long term and that can be supported. I wouldn't mind coding something up that would work well, but I don't really like or want to maintain it (triage issues, review PRs, etc.).

[epicserve]

BTW, I created this issue in django-cache-url to see if the owner (@ghickman) would want to bring that library back.

[epicserve]

@sloria,

I worked with ghickman to bring back django-cache-url and I can make a PR to include it in environs.

I would also like to get your thoughts on long-term support. I think it would be worth considering creating a Github organization called environs and then create two new projects in the organization one for Django and Flask that both use environs, but have all the URLs configs that are needed for Django and Flask. This way if your working on a Django project, for example, you could just install one dependency. So instead of installing with pip install environs[django] you could install with django-environs for example. Also, the idea would be that the sub-projects for Django and Flask wouldn't have any dependencies other than environs. Already for Django you currently have dj-database-url, dj-email-url, with possibly a third one with django-cache-url and I'm already finding for my django-base-site I need another for django-redis-sessions, so that would be four dependencies.

This would also hopefully setup environs and sub-projects for Django and Flask for others to help support the projects, with the goal of environs and the sub-projects being the defacto libraries for any project that needs 12factor configuration.

Any thoughts?

[sloria]

I worked with ghickman to bring back django-cache-url and I can make a PR to include it in environs.

Great!

I think it would be worth considering creating a Github organization called environs and then create two new projects in the organization one for Django and Flask that both use environs, but have all the URLs configs that are needed for Django and Flask.

I'm open to this. There's no actual need for flask-environs since there's no extra deps nor flask-specific API. But I see your point re: maintenance of django-environs.

This would also hopefully setup environs and sub-projects for Django and Flask for others to help support the projects,

Are you volunteeering to be maintainer of django-environs? =)

[epicserve]

@sloria,

I could probably try to find time to help get it started and also be a maintainer, but I don't want to be the maintainer. My higher-level thinking is that it would be great to find several maintainers and find a workflow and structure for contributing that has been successful in other projects and adopt it for the environs organization.

The goals would be:

• To have a proven workflow structure
• To have enough maintainers to help support environs

[sloria]

OK. An alternative for the short-term could be to keep Django code in environs. It's quite minimal ATM. There's advantages from a maintenance perspective--shared infra and boilerplate, avoids API divergence (since everything gets tested together). I'd be happy to give you maintainer privs so we can share the load. We can always re-consider splitting the Django stuff into a separate lib later.

A less important point: the name "django-environs" may confuse people given that "django-environ" already exists. I foretell that the issue trackers for both projects will get issues for the other 😄

[epicserve]

I like your short-term idea. So the first step would be to create a PR that adds the needed Django URLs to this project? That initial PR might be biggish and I would want some feedback so we could keep the code clean. Any ideas on how to make that easily digestible. It might be could to talk about what shared utils to create also.

[sloria]

Sure, maybe start a WIP PR to get things going.

One route you might go if you end up adding lots of these Django parsing libs is to publish a kitchen-sink lib that packages them all together. Your call on that.