Am 30.05.2010 um 05:54 schrieb BrettH:
> +1 on Option 2.
>
> I have written a basic deployment app (not quite ready for release
> yet) that deploys a virtualenv for each version of your project,
> roughly equivalent to Google App Engine. I specifically need to split
> out the USER_MEDIA so that it isn't versioned. Internally if the
> developer does not use the setting I will default to the MEDIA_ROOT
> anyway.
Note, my propsal isn't about creating a deployment tool but to make sure Django
is prepared for the increasing number of apps that ship with media files.
django-staticfiles is in use today due to Pinax and doesn't make assumptions
about your custom deployments. (e.g. override the storage backend to build the
media on S3)
> I like the limited focus of this proposal. USER_MEDIA nicely describes
> something that is not specifically meant or available to be deployed
> by default as part of the app, and is a reasonable convention to
> encourage developers to split their directories from the start.
Agreed, the ambiguity of the MEDIA_ROOT setting is unfortunate but not that
easy to fix in a backwards incompatible way if we also want to solve the app
media problem.
> A more complicated discussion is that around assumed app media
> directories. I'm inclined to think that admin gives the precedent to
> declare a default media directory per app, a convention that can be
> backed up by management command to link/consolidate by app name for
> production which other apps already do, but this in turn opens the can
> of worms that is settings when overriding defaults. I think ponies
> will cry if this proposal gets extended to try and include too much.
Honestly, I strongly believe this is a topic in which Django needs to provide
optional helpers to make it easier to ship non-Python files. Since a vast
amount of apps out there already ship with media files, nicely wrapped in
Python packages, ready to be installed with pip, Django only needs to be made
aware of those conventions.
Speaking of which, the admin is actually a bad example since it uses an own
legacy WSGI handler ("AdminMediaHandler") from long ago to serve its media
files. staticfiles abstracts that feature, is backwards compatible and follows
the simple idea of namespaces -- similar to how app template directories are
prefixed with the app name, <app_label>/media/<app_label>/*. So say you want to
ship media files with your app 'my_blog', it'd look like this:
my_blog
├── __init__.py
├── admin.py
├── media
│ └── my_blog
│ ├── css
│ │ ├── base.css
│ │ └── forms.css
│ ├── img
│ │ └── logo.png
│ └── js
│ └── ads.js
├── models.py
└── views.py
And you'd be able to use <static URL>/<app_label>/img/logo.png in your
templates to point to the right location of your app media files. Either use
staticfiles' file serving view (for debugging), which knows how to resolve the
relative path to the file included in the app, or use the build_static
management command, that can be called from a fabric script during deployment.
FWIW, I've started with an experimental branch at
http://github.com/jezdez/django/tree/staticfiles if you want to follow along.
Jannis
> On May 28, 1:23 am, Luke Plant <l.plant...@cantab.net> wrote:
>> A Django 1.3 proposal. It is a pretty small feature/change in some
>> ways, but needs some discussion.
>>
>> = Motivation =
>>
>> This is intended to make it easier to cope with the distinction
>> between user provided media and developer provided media. This is a
>> significant pain point when it comes to source
>> control/deployment/backup.
>>
>> For example, it would be much better when uploading my source if I
>> could do 'rsync --delete', so that the files on the server are exactly
>> what I expect - extra files can cause all kinds of bugs. But I can't
>> do that, as it would delete all the user uploaded media (or at least
>> the symlinks to it). Nor can I simply upload to a fresh directory - I
>> would still need to mess around with symlinks or moving files to get
>> user uploaded media where it is expected to be.
>>
>> Also, for security it would be good to have the whole source code
>> directory (including templates, javascript etc) to be write protected
>> from the point of the webserver. But user uploaded files mess that
>> up.
>>
>> = Options =
>>
>> We could:
>> 1) add 'STATIC_URL' and use it for widgets and all other media.
>> 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for file
>> storage.
>>
>> (using backwards compatible defaults either way).
>>
>> If 1), then, additionally, do we need 'STATIC_ROOT' as well? What
>> for? It wouldn't be used anywhere in Django.
>>
>> I was going to go for 1), like the ticket suggests, but I now think
>> that 2) is a much better idea.
>>
>> I strongly suspect that static media are far more common than user
>> uploaded files, so doing 2) will require far fewer changes to existing
>> apps. Also, I suspect that almost all direct use of MEDIA_URL in apps
>> will be for static media: file fields provide a URL attribute which
>> automatically includes MEDIA_URL, but it will be common to use
>> MEDIA_URL for calculating URLs (e.g. in templates).
>>
>> Also, use of 'media' for static media is consistent with
>> ADMIN_MEDIA_PREFIX, which is lost with option 1)
>>
>> If we go with 2), there is a good case for not adding USER_MEDIA_URL
>> to the media context processor - I can't imagine know when it would be
>> needed in the normal case. If you want to generate a URL to a file
>> stored in a model, the only sensible way to do it is
>> instance.somefile.url, which handles it for you. If we go for 1) we
>> will need both STATIC_URL and MEDIA_URL in the media context processor
>> for backwards compatibility.
>>
>> Are there any common uses cases I have not accounted for?
>>
>> Finally, once these things are sorted out, is this a small enough
>> change that I should go ahead and commit it, or should I wait for
>> voting on Django 1.3 features?
>>
>> Thanks,
>>
>> Luke
>>
>> --
>> "Oh, look. I appear to be lying at the bottom of a very deep, dark
>> hole. That seems a familiar concept. What does it remind me of? Ah,
>> I remember. Life." (Marvin the paranoid android)
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
