proposal: post-collectstatic signal

[Justin Holmes]

Currently, our only built-in management signal is post-syncdb.

I propose (and, notwithstanding objection, will build) post-collectstatic. 

Is this reasonable?  Is there another, less invasive way to hook logic into collectstatic?

--
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

[Alex Gaynor]

What's the use case?

Alex

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

[Justin Holmes]

My sense is that there are a growing number of use cases, but the one that I currently have in mind is for django-coldbrew.      I want to be able to compile all the coffeescript in a project during the collectstatic process.  Currently, we have a management command, "collect_coldbrew" - but I'd like to allow users to have this occur automatically during collectstatic.

I'm not sure if the best timing for the signal is at the end of the complete collectstatic process or at the end of each iteration (ie, one signal for each static directory that django finds).

[Bruno Renié]

On Sun, Nov 11, 2012 at 5:09 PM, Justin Holmes <jus...@justinholmes.com> wrote:
> My sense is that there are a growing number of use cases, but the one that I
> currently have in mind is for django-coldbrew. I want to be able to
> compile all the coffeescript in a project during the collectstatic process.
> Currently, we have a management command, "collect_coldbrew" - but I'd like
> to allow users to have this occur automatically during collectstatic.

In this case it seems you could just override the collectstatic
command. That's what contrib.staticfiles does with runserver, which is
a core command that gets overridden when you add the staticfiles app
to your INSTALLED_APPS.

From the get_commands [0] code it looks like the last app in
INSTALLED_APPS takes precedence, so adding 'coldbrew' after
`staticfiles` in INSTALLED_APPS would override the default
collectstatic command with coldbrew's extended version.

[0] https://github.com/django/django/blob/master/django/core/management/__init__.py#L79-123

Bruno

[ptone]

On Sunday, November 11, 2012 8:09:23 AM UTC-8, Justin Holmes wrote:

My sense is that there are a growing number of use cases, but the one that I currently have in mind is for django-coldbrew.      I want to be able to compile all the coffeescript in a project during the collectstatic process.  Currently, we have a management command, "collect_coldbrew" - but I'd like to allow users to have this occur automatically during collectstatic.

Why not have your collect_coldbrew wrap collectstatic - then you have one command?

While there are parts of the staticfiles API that should probably be opened more some day - for now it is a relatively private API.  What Bruno has suggested uses technically private API.

Such a signal as proposed would seem to be a way around https://code.djangoproject.com/ticket/15213 - and introducing a signal for such a narrow use is gonna be the wrong way to address this.

There are a couple other alternatives:

A custom storage backend (public API) that does the compiling before writing the file (this could feel unintuitive).

or use django-compressor which handles this action via template tags:

http://django_compressor.readthedocs.org/en/latest/settings/#django.conf.settings.COMPRESS_PRECOMPILERS

-Preston

[Jannis Leidel]

On 11.11.2012, at 17:09, Justin Holmes <jus...@justinholmes.com> wrote:

> My sense is that there are a growing number of use cases, but the one that I currently have in mind is for django-coldbrew. I want to be able to compile all the coffeescript in a project during the collectstatic process. Currently, we have a management command, "collect_coldbrew" - but I'd like to allow users to have this occur automatically during collectstatic.

The collectstatic command calls a method "post_process" method [1] of the staticfiles storage if it exists and passes a list of file paths that have been collected [2].

In other words, hooking into collectstatic is as easy as writing an own subclass of StaticFilesStorage (or whatever storage backend you've set STATICFILES_STORAGE) and implement the method.

Would that suffice for your use case?

Jannis

1: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.StaticFilesStorage.post_process
2: https://github.com/django/django/blob/master/django/contrib/staticfiles/management/commands/collectstatic.py#L116-127

[Justin Holmes]

Ptone: Coldbrew already uses a templatetag for development, but for production, we want people to be able to have the collectstatic experience and simple find collected coffee as compiled JS in their static directories.

As you suggest, I have reluctance about Bruno's solution.  Also, I'd be concerned about the message sent to future generations by amending the docs to read, "ensure that 'coldbrew' appears after 'staticfiles' in your INSTALLED_APPS tuple."

Wrapping collectstatic is an enormously simple and elegant solution - to my knowledge, this hadn't even crossed our minds at slashRoot. 

Janis: I hadn't noticed that we can obtain a list of collected paths from post_process - this is wonderful!  This seems like a winning solution at least for obtaining a list of directories in which we need to search for unbrewed coffee.  Come to think of it - is this the best way to do this?  Or is there a STATICFILES_STORAGE agnostic way of obtaining an authoritative list of staticfiles locations?

My only concern is that we'll limit our audience by requiring users to use a specific STATICFILES_STORAGE.  What if they're already using a custom one?

[Donald Stufft]

On Tuesday, November 13, 2012 at 10:43 PM, Justin Holmes wrote:

My only concern is that we'll limit our audience by requiring users to use a specific STATICFILES_STORAGE.  What if they're already using a custom one?

 Put the meat of your backend in a mixin, provide options for the default ones, and

instructions on mixing it into custom ones.

[Luke Plant]

On 14/11/12 03:43, Justin Holmes wrote:

> My only concern is that we'll limit our audience by requiring users to
> use a specific STATICFILES_STORAGE. What if they're already using a
> custom one?

One solution is to have your own COLDBREW_STATICFILES_STORAGE_BACKEND
setting, which can be used if people have their own STATICFILES_STORAGE,
and your one wraps it. django-mailer uses that approach to allow it to
wrap whatever real email backend people are using.

Luke

--
"It is a truth universally acknowledged, that a single man in
possession of a good fortune, must be in want of a wife." (Jane
Austen)

Luke Plant || http://lukeplant.me.uk/