Re: Just a crazy idea..
On 10/03/2012, at 1:13 PM, h3 wrote: > And this idea is just: a patch server. > > Imagine a site where developers can browse, upload, rate and comment > patches. Something like django snippets, but instead of snippets, it's > patches for django. > > A developer can upload a patch (linked or not to a ticket), specify > the django version with which it is compatible and add revisions. > Other users can rate, comment and propose revisions. > My immediate reaction -- how does this "patch server" differ significantly from a site like Github or Bitbucket? It seems to me that everything you have described here is already possible using a DVCS community site like these two. > In my dreams, applying a patch to a django installation would be > simple as editing a buildout.cfg and add those lines: > > [django_patches] > email_username = http://server.com/user/email_username/ rev=12 > no_admin = http://server.com/anotheruser/no_admin/ Something like: pip -e hg+http://bitbucket.org/user/project-name@@egg=project-name ? > It would make the future development of django a lot more community > centric, more tested and more discussed. > > To eager developers who wants new feature implemented in core, we > could just say "go on, make a patch and prove your point" instead of > debating it on a mailing list. > Which is what we already say: https://docs.djangoproject.com/en/1.3/internals/contributing/#branch-policy > Other people could then try it, use it and improve it before it is > implemented in core. > > Like I said, just a crazy idea .. or a cool GSoC project ? :) Regardless of any other merit, this wouldn't get accepted for GSoC. GSoC is very specific about their project guidelines, and their guidelines dictate that the work undertaken by students has to be directed at the core code of the project itself, not at building infrastructure to support the project. Yours, Russ Magee %-) -- 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 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.
Re: [GSoc 2012]: Want to work on keeping django code uptodate with the best practices
On 10/03/2012, at 3:48 PM, Karthik Abinav wrote: > Hi, > > I was looking through the google summer of code 2012 wiki page and found > the "Best practices updates" problem interesting and would like to work > towards it. It would be really nice, if someone could explain in more detail > as to what exactly is expected there. I am moderately comfortable with the > code base. So, references to code and the problems along the way would also > be useful. I'm not really sure what extra information you're looking for here. The project proposal seems fairly clear to me -- find features that have been added in recent Django release, then find all the places where Django itself (and in particular, the contrib apps) could be using that feature. Rinse and repeat until you have enough weeks to fill a 12 week project plan. Project validation (ticket #8579) and URL namespacing are two areas that have been specifically identified as candidates. However, these aren't the only areas where Django has failed to eat it's own dogfood. If you're interested in submitting a proposal for this project, your elaboration process will be to work your way through the 1.1, 1.2, 1.3 and 1.4 release notes, and find all the places where Django could make better use of it's own feature set. We're not going to just give you all the answers -- if you want us to commit to mentoring you for 3 months, you need to prove to us that you are capable of elaborating an idea and developing a proposal that is a valuable contribution, and achievable in the timeframe. Yours, Russ Magee %-) -- 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 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.
Re: authentication by email
On 10/03/2012, at 1:52 AM, Joe & Anne Tennies wrote: > While, I generally agree with the current approach, especially this close to > release. I'm going to play devil's advocate for a bit. > > Schema migrations have been talked about for quite a while. There are at > least 3 external implementations I know of: South, nashvegas, and > django-evolution. I'm unsure of the status of django-evolution, but the other > two appear quite active. Django Evolution isn't dead. It's sleeping. It's got lovely plumage, you know... :-) Seriously -- I stopped working on Evolution several years ago. I formally handed over the project to Christian Hammond almost 2 years ago, but this has been mostly for maintenance purposes, rather than active development. For the benefit of posterity, I blogged about the reasons [1]. [1] http://cecinestpasun.com/entries/end-my-evolution/ > A concern in my mind is that all three go off and do things totally different > ways, and the migration path to a common standard is more difficult. > > I love the idea of not choosing a tool to make the migrations, but instead > add to the ability to execute migrations. Now comes the conversation of what > that means. I would love to try to get this in to Django 1.5. A lot of this conversation has already happened, and it has core team approval. Most of these discussions were elaborated in last year's aborted GSoC 2011 project; search the django-dev archives from this time last year to see the details of what was being proposed. The short version: * Add a db.backends module to provide an abstract interface to migration primitives (add column, add index, rename column, rename table, and so on). * Add a contrib app that performs the high level accounting of "has migration X been applied", and management commands to "apply all outstanding migrations" * Provide an API that allows end users to define raw-SQL migrations, or native Python migrations using the backend primitives. * Leave the hard task of determining dependencies, introspection of database models and so on to the toolset contributed by the broader community. Under this approach, South would still need to exist, but it would be a tool leveraging the primitives exposed by Django itself. Over time, more features from South (and any other migration support projects that emerge) could be merged into trunk as the community converged on a feature set or an implementation. One of the big issues that needs to be addressed is testing -- we need to have the infrastructure that allows us to check that migrations have been applied. Arthur Koziel's AppRefactor (a GSoC 2010 project) has some analogous testing problems, so getting migrations into trunk may be dependent on getting the App Refactor into trunk as well. The good news is that the App Refactor also forms the likely stub for fixing the auth.User problem -- but that's a separate discussion. > Now on to the meat of what I really want: > Is there something along the lines of the GNOME design group for Django? > (example: https://live.gnome.org/Design/Apps/Web). I'd love a template for > the wiki or even better an app to discuss these things. If only we had some > web developers ;) So, is there a sanctioned tool already out there? Or should > I start building up a page on the wiki for this? I think most things become > much easier once one gets a blueprint and requirements for what the design > goals are. Especially if one can get an initial "this looks acceptable" by a > core committer before "wasting one's time" because the requirements weren't > even correct. There are some historical examples where we've used the wiki to elaborate on an idea as a precursor to getting a feature into core. https://code.djangoproject.com/wiki/SessionMessages https://code.djangoproject.com/wiki/ClassBasedViews https://code.djangoproject.com/wiki/LoggingProposal https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl (The first two are probably the best examples to follow) There is a wiki page which has been used in the past to discuss schema evolution (which it looks like you've found); however, it's wandered a little off the reservation. There's probably some good material in there still, but if someone is looking at this, it would benefit from some manicuring, and probably a complete reboot: https://code.djangoproject.com/wiki/SchemaEvolution There isn't a specific wiki template that we require -- this is mostly because every project has slightly different requirements. However, the broad format is fairly common: * describe the problem * describe any specific design constraints * describe the possible approaches and their benefits/limitations * list any prior art * list any draft implementations If you want to work on this, I can guarantee that you would have as much support as I and Andrew Godwin (South maintainer and Django core developer) can muster. This is one of the big ticke
Case-insensitive collations and ModelMultipleChoiceField?
I may have found a bug in Django but wanted to run it by the core
developers before I filed a ticket. It concerns validation of a
ModelMultipleChoiceField when using a case-insensitive database
collation (in our case, a MySQL database with collation set to
'utf8_general_ci').
First some background: Our application has a feature that allows users
to add or modify objects using an uploaded CSV file. Some of these
objects have short string-based primary keys, so users can reference
them in the CSV using a code name familiar to them instead of an
esoteric auto-increment ID. These exist in the database is all
uppercase, but users often enter them in the CSV with all lowercase
(or sometimes with initial cap).
Since we use model forms to validate the data, this case disparity
causes ModelMultipleChoiceFields to fail validation, even though in
other contexts the strings compare equal, e.g.
Foo.objects.get(pk='bar') and Foo.objects.get(pk='BAR') both succeed
and return the same object.
Looking at the code, it appears that Django does a strict comparison
of values given in a ModelMultipleChoiceField by doing a membership
test:
https://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L1028
However, the same is not true of a ModelChoiceField, which considers a
pk valid if get() succeeds:
https://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L986
This is weirdly inconsistent:
Foo.objects.create(name='BAR') # `name` is the pk
f = ModelChoiceField(queryset=Foo.objects.all())
f.clean('BAR') # succeeds
f.clean('bar') # succeeds
f.clean('bAr') # succeeds
f = ModelMultipleChoiceField(queryset=Foo.objects.all())
f.clean(['BAR']) # succeeds
f.clean(['bar']) # FAILS! ValidationError: [u'Select a valid
choice. bar is not one of the available choices.']
This is not an issue with case-sensitive collations like utf8_bin, but
for others it seems like the validation behavior should take collation
into account in a consistent way.
Shall I file a bug?
--
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 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.
Re: [GSoc 2012]: Want to work on keeping django code uptodate with the best practices
Hi, Thanks a lot for the hints and suggestions .I shall soon come back with a detailed groundwork on the various areas that django could make use of its own feature set. On 10 March 2012 14:04, Russell Keith-Magee wrote: > > On 10/03/2012, at 3:48 PM, Karthik Abinav wrote: > > > Hi, > > > > I was looking through the google summer of code 2012 wiki page and > found the "Best practices updates" problem interesting and would like to > work towards it. It would be really nice, if someone could explain in more > detail as to what exactly is expected there. I am moderately comfortable > with the code base. So, references to code and the problems along the way > would also be useful. > > I'm not really sure what extra information you're looking for here. The > project proposal seems fairly clear to me -- find features that have been > added in recent Django release, then find all the places where Django > itself (and in particular, the contrib apps) could be using that feature. > Rinse and repeat until you have enough weeks to fill a 12 week project plan. > > Project validation (ticket #8579) and URL namespacing are two areas that > have been specifically identified as candidates. However, these aren't the > only areas where Django has failed to eat it's own dogfood. > > If you're interested in submitting a proposal for this project, your > elaboration process will be to work your way through the 1.1, 1.2, 1.3 and > 1.4 release notes, and find all the places where Django could make better > use of it's own feature set. > > We're not going to just give you all the answers -- if you want us to > commit to mentoring you for 3 months, you need to prove to us that you are > capable of elaborating an idea and developing a proposal that is a valuable > contribution, and achievable in the timeframe. > > Yours, > Russ Magee %-) > > > > > -- > 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 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. > > Thanks, Karthik Abinav -- 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 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.
