Primary Key AutoField -> UUID Field

AutoField (auto-incrementing integer). I’d like to be able to automatically use a UUID field, but then still be overridden in a specific model if I specify a different primary key. Brian Carter brianrcarte...@gmail.com -- You received this message because you are subscribed to the Google Groups

Re: Deadlock bug in logging? Reproducible case

Nah, I'm good — but thank you! On Friday, April 24, 2020 at 8:57:09 AM UTC-4, René Fleschenberg wrote: > > Hi, > > On 4/23/20 12:20 PM, Adam Johnson wrote: > > What version of Python René? > > I tested with 3.6.7. I can test with other versions, if that helps. > > Regards, > René > > > > --

Re: Deadlock bug in logging? Reproducible case

True, I did notice it needed some more tweaking. I've got a long evening of rewriting years' worth of wsgi.py's and Apache configs ahead of me. I'll probably just jump straight to the envparse approach because (as you noted) my celery env var handling was making the WSGI approach moot anyway. N

Re: Deadlock bug in logging? Reproducible case

Beautiful. That does the trick. Thank you! And I certainly can see there's plenty of other approaches such as envparse or django-environ that I could be using, that keeps the vars out of my Apache config. Quick fix and a slighly longer better fix. This'll change how I do all my new projects fro

Re: Deadlock bug in logging? Reproducible case

FYI, here's where that approach came from -- http://ericplumb.com/blog/passing-apache-environment-variables-to-django-via-mod_wsgi.html > > It's the top hit for "django apache environment variable" Which is literally an old friend of mine from grade school. Maybe that's a red flag ... -- You

Re: Deadlock bug in logging? Reproducible case

ading.py", > line 932 in _bootstrap_inner > File "/Users/chainz/.pyenv/versions/3.8.2/lib/python3.8/threading.py", > line 890 in _bootstrap > > This stood out to me. I checked your wsgi.py , it contained: > > def application(environ, start_response): > retu

Re: Deadlock bug in logging? Reproducible case

Tom > > On 23 Apr 2020, at 12:40, Brian Tiemann > > wrote: > > It also happens in 3.6.9, which is my prod environment. > > FWIW, by way of background context, this is not a heavily used app, not > enough so to warrant logging to a custom buffered consumer or remote age

Re: Deadlock bug in logging? Reproducible case

mportant, in other words; it's that the whole app is wedging just because I happen to have a vanilla LOGGING setup configured. On Thursday, April 23, 2020 at 7:02:11 AM UTC-4, Brian Tiemann wrote: > > Hi — Thanks for looking into this. Adam, I skipped over details like the > Python v

Re: Deadlock bug in logging? Reproducible case

/issue6721 , suggesting this was to do with thread locking. But I'm not qualified to make that call for sure, so I don't want to throw red herrings into the mix. If "standstill" is a better term for this that's what I'll use. Thanks again. On Wednesday, April 22,

Deadlock bug in logging? Reproducible case

Hi all, I was directed here after getting corroboration on #django and elsewhere. I have what appears to be a bug in which a Django app can deadlock if you hit it with a lot (>3) of AJAX requests within a short time (i.e. all triggered in parallel from a single HTML page). I have a reproducible

Re: Deprecating logout via GET

I’m on the other side of the fence – I don’t think this is a necessary change. The examples given in historic tickets are not worthy of a change like this in my opinion. For example, take the example regarding a bot crawling a website, and losing its session by crawling the logout link – if you

Welcome Mariusz Felisiak to his first day as a Django Fellow

! Warmly, Brian Moloney DSF Fellowship Committee -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developer

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

On Friday, 13 January 2017 19:22:13 UTC+11, Aymeric Augustin wrote: > > I agree that this setting has become less useful now that > has won. > > It made more sense when it wasn’t clear whether XHTML1.1 would take over > HTML4. > > I’d be interested to hear about use cases, if someone still uses

Re: Easier to use natural keys.

Sunday, December 21, 2014 9:31:22 AM UTC-5, Torsten Bronger wrote: > > Hallöchen! > > Brian Faherty writes: > > > [...] > > > > The solution I propose is a meta field on the model that allows > > you to set natural keys there. > > FWIW, we current

Re: Easier to use natural keys.

Thanks for re-linking it. I maybe should not have done it as inline. On Sunday, December 21, 2014 6:50:22 PM UTC-5, Russell Keith-Magee wrote: > > > On Sun, Dec 21, 2014 at 10:33 PM, Josh Smeaton > wrote: >> >> Would you mind linking to the ticket you're talking about? Will encourage >> more pe

Easier to use natural keys.

oses a change that they think would be necessary to accept this idea. Brian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an

Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

Dear All: After reading this discussion I see that my fears were misplaced. I can now see that schema migrations are not necessary to stop using the AUTH_PROFILE stuff thanks to the explanations from Russ and Carl. Had I done a bit more investigating I probably would have realized this. Sorry f

1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

Hello, The deprecation timeline says this about Django 1.7: "The AUTH_PROFILE_MODULE setting, and the get_profile() method on the User model, will be removed." The dev 1.7 release notes say that the new schema migration is scheduled to land in 1.7. Does this mean we cannot use the new schema

Re: unittest.TestCase vs. django.test.TestCase in overview example

from django.utils import unittest". which causes a very non-obvious unit test failures in the most typical test cases. Thanks for reconsidering the patch! Lorin's version is much clearer. Brian On Mar 25, 2013, at 2:08 PM, Tim Graham wrote: > It seems like it could be a dangerous

list your group on djangonauts.org

ed by DjangoCMS). Check it out. List your site. Spread the word. Follow @djangonauts_org. Brian Moloney -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.co

Re: Allow changing form field properties after form creation

On Thursday, April 5, 2012 6:49:20 AM UTC-5, Chris Wilson wrote: > > Hi all, > > I've added this as a ticket but I wanted to make sure that the core > and forms developers have a chance to see and interact with it, so I'm > posting it here too. You can find the ticket at: >

Re: Tests introduced in patch for #17327 causing errors

er is more appropriate. Brian On Wednesday, March 7, 2012 at 8:11 AM, Brian Riley wrote: > Thanks for catching this. I worked on that patch. > > The problem is that those two test cases shouldn't be in the auth tests but > rather somewhere in top-level tests folder (with the other

Re: Tests introduced in patch for #17327 causing errors

suggest a location, I'd be happy to move them and submit the patch. Brian On Mar 7, 2012, at 7:11 AM, Calvin Cheng wrote: > > Thanks. I stumbled upon the same problem. > > > On Wednesday, March 7, 2012 4:40:56 PM UTC+8, Ryan Kaskel wrote: > Hi all. > > I'

Re: Python 3 and you

If you want to test Linux deployment, install Ubuntu under VirtualBox: https://www.virtualbox.org/ Brian Schott bfsch...@gmail.com On Nov 8, 2011, at 11:37 AM, richard.prosser wrote: > Yes I know but Vista isn't the best platform and my laptop isn't that > hot! > > Plus

Re: login_required decorator and user.is_active (yes, again)

On Oct 5, 2:59 pm, ptone wrote: > 13125 was wontfixed by Jacob at the end of the summer, this relates to > the login_required decorator not checking for user.is_active > > I had opened a duplicate ticket 16996 before catching it as a dupe > > I'm going to dredge this one back up. ... > I think t

Re: confusing things in Trac UI (was: Design decision for #1625...)

On Sep 20, 4:16 pm, Carl Meyer wrote: > > Yeah, this is confusing in our Trac UI. The "accept" radio button at the > bottom assigns the ticket to you, it doesn't actually do anything with > the triage state. To change the ticket from DDN to Accepted you'd use > the dropdown next to "Triage Stage"

Re: Wrong error message when user having is_staff=False tries to login to admin

ecurity issue, and have provided examples. At this point, I'll absolutely never forget to check the is_staff flag purely because I've been following this discussion. What I don't understand is why there is such a huge opposition to the change. -- Brian O'Connor -- You receive

Re: Wrong error message when user having is_staff=False tries to login to admin

d have > applied the same security measures in the first place. So yes, this > most likely is not a security issue at all. > > If your admin site is on a protected intranet, are we really trying to protect against a brute force attack? -- Brian O'Connor -- You received this messag

Re: Wrong error message when user having is_staff=False tries to login to admin

e database, you allow the attacker to stop their attack short when they find the a user with invalid permissions, and go to the next account. This doesn't seem like enough benefit to justify having a confusing message presented to legitimate users, at least in my opinion. -- Brian O'C

Re: Wrong error message when user having is_staff=False tries to login to admin

' or something akin to that. I'd like to see this fixed as well. -- Brian O'Connor -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com

Re: Various small issues

On Jan 31, 7:35 pm, Russell Keith-Magee wrote: > > The core team aren't the only people who can review tickets. In fact, > all you need is for someone who isn't you to review your ticket and > say that it looks good (by Django's standards -- which means > documentation, tests, PEP8 etc). Once you'

Re: Enabling context access in simple_tag

> > As an example of what I'm talking about -- #14262 is a manifestation > of a use case that is undeniably simple: "get_function() as var". This > pattern is used in several places in Django's own codebase. To that end, I'm willing to be practical and concede that adding takes_context > would

Re: contrib.staticfiles settings suggestion

On Nov 4, 3:06 am, Jannis Leidel wrote: > Ok, thanks for your input, would you mind creating a ticket describing the > discrepancy in more detail? I thought the how to [1] explains enough of > purpose of the app, so any further input would be much appreciated. > > > I'd be glad to help, but I'm

Re: contrib.staticfiles settings suggestion

On Nov 3, 4:12 am, Jannis Leidel wrote: > > No, MEDIA_* and STATICFILES_* settings aren't the same, the former is for > user generated content (like file uploads), the latter for general static > files your site needs to work (such as css/js files). The distinction is also > well described in t

Re: #6375 -- Class Based Views: Opinions on commit plan

On Oct 16, 2:34 am, Gabriel Hurley wrote: > > What do you call this. I don't see how any software developer could > > consider constructive criticism as anything other than helping out. > > You've posted three messages in this thread, but none of them seem > "constructive" to me. You've pointed ou

Re: Inclusion of easy-thumbnails into Django Contrib

gt; probably not as easy for the crowds. The other is "easy-thumbnails". > > On Sep 16, 10:33 am, "Brian O'Connor" wrote: > > I have absolutely no pull in decision making, but maybe my message will > > count towards a "community voice". > > >

Re: Inclusion of easy-thumbnails into Django Contrib

roups.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 a

Re: Feature request - set variables in template

I think this got brought up in the forums a month or so ago, but I'd like to see a 'shortcut' for setting variables much like we have a shortcut for registering inclusion templatetags. Having to write a full fledged templatetag to set a variable is a bit much. Brian On Thu, Aug 2

Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.

jango core, going about it with the tone of "how could this not already be in the core" probably won't buy you much. Proposing potential solutions and starting relevant, well articulated discussions on the topic might get the ball rolling in that direction though. Just my $0.02. -

Re: Imports in the tutorial

different ways to do it * each has its (subjective) pros/cons * Django isn't endorsing a particular style but has chosen one for the sake of convenience in the tutorial -Brian . On Jun 12, 7:34 am, Andrew Godwin wrote: > On 12/06/2010 01:03, Russell Keith-Magee wrote: > > > What - ver

Re: Static media handling - ticket 12323

? If someone changes the name of the app there is no way they will get by without modifying source code in the app. Why should this be any different? I wouldn't really buy the argument that it reduces the amount of change they'd have to do. It applies to the convention people use when st

Re: Static media handling - ticket 12323

oint. > 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? I suppose this is dependent on whether we want to introduce app media handling or if we want this to separat

Re: Upgrading Trac

> > Who has access to the server? What do I need to do to convince to let > me upgrade? I've volunteered off-list by speaking to Jacob. We were supposed to meet up this week, but haven't made contact yet. I do plan on helping/performing the upgrade to 0.11.X. I do not yet kno

Re: dbsettings, and user configurable app settings

e same problem we are. If there is a solution you have in mind that magically solves everyone's problem nicely then present that instead of hand waving. Brian Rosner http://oebfare.com http://twitter.com/brosner -- You received this message because you are subscribed to the Google Groups

Re: #9015 — signal connection decorator

a bad idea. It does reduce an import and does help make it more clear than using connect. I'd be in favor of changing it to this. Brian Rosner http://oebfare.com http://twitter.com/brosner -- You received this message because you are subscribed to the Google Groups "Django develope

#9015 — signal connection decorator

Hey all — I wanted to get some feedback on a patch [1] I wrote for #9015. I am on board with the notion decorators can be used for registration patterns. Recently, I've been using signals a bit more which has spiked my interest in this ticket. Since Django 1.2 has a Python 2.4 minimum requireme

Re: Model validation incompatibility with existing Django idioms

, but it won't work as I presented it. I think having the > model track which validators have been run and which haven't is a > non-starter. That's something Honza actively avoided in the design. Saw this after my e-mails. This does present an issue. For sake of backwards co

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 3:57 pm, Brian Rosner wrote: > Yeah, I think that must have been a typo in Joseph's mail. The way I read it > that the model knows what fields it has already validated and the call to a > Model.save would validate the rest. Actually, I just realized that Model.s

Re: Model validation incompatibility with existing Django idioms

o to fix the idiom, the excluded field validation > would need to be done on Model.save, not ModelForm.save, right? Yeah, I think that must have been a typo in Joseph's mail. The way I read it that the model knows what fields it has already validated and the call to a Model.save would v

Re: Model validation incompatibility with existing Django idioms

The naming is a bit off, but that can be worked out. Unfortunately, we couldn't much with it now, but I'd like to look at the possibility for 1.3. Thanks for sharing. Brian Rosner http://oebfare.com http://twitter.com/brosner -- You received this message because you are subscribed to the

Re: Model validation incompatibility with existing Django idioms

ases where there was real developer error. Brian Rosner http://oebfare.com http://twitter.com/brosner -- 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 un

Re: Advocacy for Email-01 (email backends)

with with many of the details of the original proposal and was afraid of over-complication. Thanks for putting in the work to get this ready for commit, Russell. Brian Rosner http://oebfare.com http://twitter.com/brosner --~--~-~--~~~---~--~~ You received this me

Re: Django 1.2 proposal: revisit admin autodiscover improvement for custom sites

cumentation and tests and attaching it to #8500. Of course I welcome the thoughts of others too. Brian Rosner http://oebfare.com http://twitter.com/brosner --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django d

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

I'll just file a > documentation ticket. No doubt the documentation needs to be revised slightly for this. It is mentioned, but only as a single sentence that almost makes no sense ;-) Please file a ticket for the documentation fix it would be greatly appreciated. :-) Brian Rosner ht

Re: GSoC Status update (week 2) - HTTP & WSGI Support

w hours of time. > As always, there are multiple approaches and I don't want to slight or > invalidate Brian's experiences. It's definitely a case of doing whatever > works easiest for oneself and trying out a few options initially is > encouraged, t

Re: GSoC Status update (week 2) - HTTP & WSGI Support

ou can fork from and keep your local repository in-sync with upstream changes. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this gro

Re: Patch status for ticket #9122

generally acceptable. I'd like to see some documentation on it. I will definitely review this in time for 1.1. Thanks for the heads up. Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google G

Re: Proposal: New transaction API with multiple databases

rk really well. Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To uns

#5903 DecimalField returns default value as unicode string

do so. Perhaps someone can shed some light on this? [1]: http://code.djangoproject.com/ticket/5903 -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" gro

Re: Sanity check #8306 (cleaning up formfield_for_dbfield), please

t a step further and figured this should be included as it does change the method signature [2]. [1]: http://code.djangoproject.com/ticket/3987 [2]: http://github.com/brosner/django/commit/d6c0a47be4a2ea7743c9e90a4accd43993b4f5bd -- Brian Rosner http://oebfare.com --~--~-~--~~---

Re: Distributed workflow and the woes of slow testsuite

running Python 2.6+. While it can be made optional, that is what it is now. I am all for its inclusion, but lets wait until it becomes, first, more stable (used by more people than me), and two, more people can actually take advantage of it out of the box. -- Brian Rosner htt

Re: Dropping Python 2.3 compatibility for Django 1.1

least 2.4 available to them or they can hang out in 1.0 land until they are able to upgrade. Remember PyCon 2008? :) -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django d

Re: 1.0.1 release blockers?

broken and that it will make the release :) -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers

Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

On Oct 27, 1:46 pm, mrts <[EMAIL PROTECTED]> wrote: > > IMHO this should be documented, so I > > reopenedhttp://code.djangoproject.com/ticket/9409 > > and changed the component to Documentation. > > I've attached the explanation > tohttp://code.djangoproject.com/attachment/ticket/9409/database_i

Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

On Oct 21, 7:27 am, mrts <[EMAIL PROTECTED]> wrote: > It seems that current DB lock management doesn't play nice with the > new Python 2.6 multiprocessing package and SQLite. See [1]. The same > error also popped up in Google search under mod_python [2]. As others have pointed out, this isn't an

Re: auto_now_add and auto_now

On Oct 13, 11:15 am, Brian Beck <[EMAIL PROTECTED]> wrote: > The only action was three months ago with a DeprecationWarning patch that > isn't checked in. ...and probably shouldn't be, since it still doesn't update the docs. --~--~-~--~~~--

Re: auto_now_add and auto_now

On Oct 13, 8:38 am, "Mike Scott" <[EMAIL PROTECTED]> wrote: > Secondly this question has been asked, and solved many times. If you search > through the django-users archives I'm sure you'll find plenty of solutions. > There are solutions out and about in the blogosphere too. Actually I think this

Re: Declarative syntax for widgets in ModelForm

On Sep 29, 10:37 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Full customization already can be done by specifying fields directly in > a form class. In my experience widgets are just very common case. I think your model_field helper being built-in (short for x._meta.get_field(y).formfield(**pa

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 25, 2:54 am, Rudolph <[EMAIL PROTECTED]> wrote: > I like Luke's arguments. > > A middleware seems like the right place because CSRF protection is > about requests and responses. CSRF protection is more about POST > requests in generic, with HTML forms being a very common type of POST > requ

Re: Running tests.py in apps without models.py

On Sep 23, 3:40 pm, "Adam J. Forster" <[EMAIL PROTECTED]> wrote: > Hi Eric, > > That's what I have done at the moment, but as you say it's a bit of a > hack and I'm not sure that I'm happy with it. I ran across this bug the other day too; quite annoying. It's ticket #3310 and there appears to be

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote: > Could we just include something like a signed salt+timestamp > +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because > of the possibility of a same-IP-CSRF (affecting people behind > proxies), but it's dead simple and doesn't re

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 23, 10:56 am, oggie rob <[EMAIL PROTECTED]> wrote: > I'm sorry, I used the wrong term here. I didn't mean that CSRF > protection isn't worthwhile, just that going the route of an extended > form might not be the best way to do it. > As for suggestions, I'm not sure I have one exactly, but I

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 22, 5:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > One thing that might help out in this case would be the ability to > create a SafeForm from a regular Form (which might be an argument for > csrf protection as a feature of django.forms.Form rather than a > subclass). If the third par

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 22, 5:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > But still, the situation dictates the need for SafeForm, not the form > author. If this becomes best practice, essentially *every* form will > need to be initialized with a request. What about something like: d

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 22, 4:55 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > > -- What about third-party app forms that aren't SafeForms, but need to > > be? The situation dictates this, not the form author. > I think we keep CSRF middleware around to deal with that. We also very > actively encourage third pa

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Sep 22, 4:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > CSRF[1] is one of the most common web application vulnerabilities, but > continues to have very poor awareness in the developer community. > Django ships with CSRF protection in the form of middleware, but it's > off by default. I'm w

Re: Proposal: label tag attributes

On Sep 15, 8:50 am, "Eduardo O. Padoan" <[EMAIL PROTECTED]> wrote: > On Mon, Sep 15, 2008 at 9:39 AM, Julien Phalip <[EMAIL PROTECTED]> wrote: > > That's a good point. Mixing {% include %} and {% with %} is both more > > verbose and less flexible than if using a custom tag. In this case, > > using

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 20, 6:58 am, Erik Allik <[EMAIL PROTECTED]> wrote: > Has anyone got some good use cases where the template-loaded mimicking   > behavior would be desired? Otherwise it's just needless complexity in   > my opinion. Well, first of all, it's not really complexity at all. If it were to just c

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 19, 4:26 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > I also have an implementation that I'll post when I get home. I just posted my collectmedia (I liked the name Rajeev used) command here: http://www.djangosnippets.org/snippets/1068/ It's a long snippet bec

Re: Proposal: installmedia command - A story for distributing media with apps

I noticed that elwaywitvac just posted this management command here: http://www.djangosnippets.org/snippets/1066/ I also have an implementation that I'll post when I get home. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]> wrote: > A problem would be referencing images, and media in css/js files. > Currently, in all our projects we use /site_media/ as the MEDIA_URL, > so this not a problem. But for a true solution, there should be a > preprocessor for css

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > I really like the idea. However, I think there should also be a way to > configure it to not copy to MEDIA_ROOT but to somewhere else. Sure - a --destination flag, defaulting to MEDIA_ROOT, would work. > Also, instead of just copying

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > Serving is totally orthogonal -- everyone is already serving up > MEDIA_ROOT in their projects somehow anyway, and this just copies > files to MEDIA_ROOT. Sorry, I guess that's not totally true -- everyone who use

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 16, 6:29 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > > Could it be a little smarter, and in the absence of specific apps, iterate > > over all INSTALLED_APPS, and install their media automagically? > > +1 for some sort of media.autodiscover(). > It would have to be optional though, as th

Re: RFC: django.template refactoring (#7806)

On Sep 16, 2:36 pm, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > Why should django.template be refactored? Filter and Variable parsing > is inconsistent. Many ad hoc parsers in defaulttags are fragile. > Whitespace handling is ungraceful. > > The patch provided in #7806[1] splits __init__.py in

Re: Proposal for 1.1: Extend inclusion tag syntax to allow custom templates (#9093)

On Sep 16, 8:37 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote: > I don't think anyone will complain that they have to type less, as its > still understandable. +1 for allow_override. Changed to allow_override. See patch #4 at: http://code.djangoproject.com/ticket/9093 --~--~-~--~~---

Proposal: installmedia command - A story for distributing media with apps

Distributing media with apps could be a lot easier. Currently this requires copying or linking files manually (possibly each time the app is updated), and this encourages developers to put CSS and JavaScript inline in their templates. I propose a management command to make this easier: $ python

Re: Altering data uploaded to FileField before save is called

hack and make going forward much simpler. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developer

Re: Altering data uploaded to FileField before save is called

operation may be very expensive. Go look for a ticket about this. If there isn't one I would say report one. This seems like a reasonable thing to do in general. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you

Re: Please force ticket 8367 to inclusion.

On Fri, Aug 22, 2008 at 2:26 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > > Hi core devs, > > could you please force http://code.djangoproject.com/ticket/8367 to > include into 1.0 asap? Please don't do this. The ticket is marked as 1.0 and is accepted. It will get i

Re: BaseModelFormSet and ModelForm.instance

On Wed, Aug 20, 2008 at 11:42 AM, Justin Fagnani <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 20, 2008 at 8:39 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: >> I am slightly unclear on what is allowed to >> be broken in this phase of Django development. I suspect it is o

Re: BaseModelFormSet and ModelForm.instance

ost-1.0 if we did decide to so something. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@g

Re: BaseModelFormSet and ModelForm.instance

your patch? If so, I suspect the coverage isn't good enough ;) -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send

Re: initial data for inlineformset_factory

r the general case due to the unknown size of the queryset. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Ability to delete contents of FileField and ImageField in admin

one > give me a status update of whether or not it is possible to delete > the contents of a FileField or ImageField from within the admin? Keep an eye on http://code.djangoproject.com/ticket/7048. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You

Re: Installing alpha over 96.x?

o have previously > installed a release should delete the old release before installing > a new one? Whatever it would take to remove those would be really ideal. Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because y

Re: Use admin.autodiscover() by default?

hat it might be an uncommon thing since most people might want a custom AdminSite instance, and boy was I wrong ;) Tweaking the tutorial would be a good idea too. Give a bit of information about it would be a good thing. Brian Rosner http://oebfare.com --~--~-~--~~---

newforms-admin branch has been merged into trunk

branch is now closed. Onward to 1.0! [1]: http://code.djangoproject.com/changeset/7967 [2]: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribe

Re: Newforms admin: Validator for ModelAdmin classes broke my admin

On Jul 17, 2008, at 4:26 AM, Ross Lawley wrote: > Hi all, > > The recent changes in newforms admin r7529 changed the validation > for newforms admin models. However, it is a bit too strict and > doesn't allow customizable admin forms to output non model fields. > > I've added a patch with t

Re: newforms-admin Status Update

On Jul 15, 2008, at 10:50 PM, Brian Rosner wrote: > The documentation is pretty much done. I would like for people to give > it some attention and shake out any problems. Not a big deal and can > be dealt with after a merge. The tutorial needs a bit of > newforms-admin love. I hav

  1   2   3   >