+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.
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. 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. 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.
