Ok yes seems like a slam dunk.. hell how about an --install-media for
python setup.py install ;)
On Jun 3, 10:18 pm, Jannis Leidel <jan...@leidel.info> wrote:
> 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
> athttp://github.com/jezdez/django/tree/staticfilesif 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
> > athttp://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.
