Hi,
It is quite common to configure TEMPLATES and STATICFILES_DIRS such that you
can override the templates and static files of installed apps from some
central location.
Maybe startproject should actually generate settings to do this by default?
STATICFILES_DIRS = (
os.path.join(BASE_DIR,
I didn’t do too much triaging and reviewing this week due to traveling and
Django Under the Hood. I started releasing 1.8.6 on a train from Brussels
to Amsterdam and uploaded it upon arrival. We had a nice day of sprints
today and now I have a plethora of pull requests to review. :-)
Triaged
The drawback of complex dictionary settings is that to overwrite only one
key in a settings file, you have to copy the entire dictionary, also
possibly defeating global settings defaults when they change.
So let's try to have many smaller dictionaries instead of few big ones. The
initial propos
+1 to these ideas. This will make injecting dependancies much cleaner. I’ve
pointed my BACKEND settings to factory functions in the past.
def storage_factory():
return SomeStorage(some_de)
DEFAULT_STORAGE_BACKEND = ‘path.to.storage_factory'
> On Nov 7, 2015, at 7:10 AM, Shai
On Saturday 07 November 2015 14:55:20 Aymeric Augustin wrote:
>
> Essentially your proposal means reformatting the current file-related
> settings to this structure:
>
> FILE_STORAGES = {
> ‘media’: {
> ‘BACKEND’: settings.DEFAULT_FILE_STORAGE,
> ‘OPTIONS’: {
> ‘l
Hello,
Indeed, if we took a big step further and provided an API to configure multiple
file storage backends, that would make sense.
Currently we have two hardcoded ones: the default, which is used for media
files, and the static, which is used for static files.
Essentially your proposal means
On Sat, Nov 7, 2015 at 11:58 AM, Raphaël Barrois
wrote:
> Hello,
>
>
> The core of the proposed solution seems quite interesting; however, it also
> introduces a new configuration format for backends.
>
> Caches and databases use a dict with a "BACKEND" key and an "OPTIONS" dict
> for kwargs to
Hello,
The core of the proposed solution seems quite interesting; however, it also
introduces a new configuration format for backends.
Caches and databases use a dict with a "BACKEND" key and an "OPTIONS" dict for
kwargs to pass to the backend.
Likewise, entries in the TEMPLATES list are dicts
I'm +1 on this solution; it solves the problem in an efficient way without
becoming unreadable. I'd shy away from the variants unless/until there's a
definite need. kwargs are more explicit, which I think is helpful in
readability :)
J
On Saturday, November 7, 2015 at 12:16:05 PM UTC+1, Aymer
I think the proposed approach makes sense.
I don't think we need to support any variant to pass the configuration
values as args. All the existing storage backends have to make their
argument optionals anyway now to support how they are currently initialized.
Requiring a dict makes it also more
I think the proposed approach makes sense.
I don't think we need to support any variant to pass the configuration
values as args. All the existing storage backends have to make their
argument optionals anyway now to support how they are currently initialized.
Requiring a dict makes it also more
Ooooh. I think I like it. The syntax could be a bit confusing, but I think
I like it. :)
On Saturday, November 7, 2015 at 12:16:05 PM UTC+1, Aymeric Augustin wrote:
>
> Hello,
>
> Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings
> contain a dotted Python path to the storage cl
Hello,
Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings contain a
dotted Python path to the storage class. The class is instantiated without any
arguments.
** Problem **
This leads to three annoyances.
1) Third-party libraries like django-storages(-redux) need to provide a
That's an excellent point, Shai - if there are migrations they might be
essential to the app functioning. I think in that case we should not have
them work on 1.7 and up, and encourage people to send PRs to the apps
moving the directory name if it would work with syncdb.
Andrew
On Sat, Nov 7, 201
No, I think we can't do this generically.
If an app ships (South) migrations, we cannot assume that syncdb is an
adequate replacement; the migrations may include data-migrations which create
records the app needs. We could in general do something like, try to verify
that there are no data migra
I think if the fix is easy, we should continue to support them past 1.7,
since we're retaining syncdb support. However, if it's crazy complicated,
it's likely not worth it.
Andrew
On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic
wrote:
> I have initially created the ticket
> https://code.django
FWI a new ticket[1] with what looks like a sane implementation to add this
level of logging to the runserver command has been created.
I'll make sure to copy all the concerns raised by Russ over there and you
might want to chime in the review process.
Simon
[1] https://code.djangoproject.com/t
17 matches
Mail list logo
