Re: Django git guidelines
I have update the working with git guidelines based on the above discussions. Here is the stats of the whole of the work: docs/internals/contributing/committing-code.txt| 108 - .../contributing/writing-code/branch-policy.txt| 171 - docs/internals/contributing/writing-code/index.txt |2 +- .../writing-code/submitting-patches.txt| 61 +++-- .../contributing/writing-code/working-with-git.txt | 228 ++ docs/internals/git.txt | 198 +++ docs/internals/index.txt |2 +- docs/internals/svn.txt | 254 8 files changed, 566 insertions(+), 458 deletions(-) The biggest changes to the previous work are: - It is not required to create "perfect" pull requests - It is recommended that the committer do the final squashing - For basic patches the suggested (though not required) workflow is: - create a trac ticket - once you have some code available, push your work to github, announce your branch in the ticket - once you have something committable available, make a pull request. Logical commits at this time are suggested. - based on reviews, add commits to your work, do not squash work at this stage, this allows the reviewer easily see what you changed. - If it seems the work is far away of being commit quality, or the patch author does not respond in reasonable time, the pull request should be closed (the patch author is free to reopen after dealing with the review issues). - once the work is ready for committer, the committer will rework the history according to her judgment. Logical commits is the suggestion, but the documentation intentionally leaves some freedom for the committer. I am sure there is still a lot to polish. I might have tried to change too big portion of the docs in one go. Still, I would like to commit what I have tomorrow, so that the sprinters at djangocon have the possibility to use the guidelines and begin the polishing work. Alternatively, if it is possible to build the docs and make them available somewhere for the sprinters, I could wait for reviews from the sprinters, then commit the code early next week. This would make for a really good review for the guidelines. The work is available from: https://github.com/akaariai/django/tree/django_git_guidelines or for compare view: https://github.com/akaariai/django/compare/django_git_guidelines - Anssi -- 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: Glad site is being brought back.
Super legendary, thank you for your efforts. -Original Message- From: Bruno Renié Sent: Wednesday, June 06, 2012 10:47 AM To: django-developers@googlegroups.com Subject: Re: Glad site is being brought back. On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski wrote: Please disregard this message, it was meant as a reply to a thread not a new thread. -Original Message- From: Daniel Sokolowski Sent: Wednesday, May 30, 2012 12:35 PM To: Django developers Subject: Glad site is being brought back. I was just about to post a public message to Simon Willison urging him to shut it down or fix the site when I found this thread. I wish to say thank you and am very grateful that you are fixing and bringing the service back. On unrelated note would it be possible to change my username on the site from: djangopeople.net/danols/ to djangopeople.net/ danielsokolowski/ ? As announced on the Django weblog, people.djangoproject.com is live :) The code currently lives on my github account [0]. Feel free to submit issues and pull requests if you have ideas for improvements on the site. I'll look at renaming usernames, in the meantime if you need anything custom just get in touch privately. Bruno [0] https://github.com/brutasse/djangopeople -- 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. Daniel Sokolowski Web Engineer Danols Web Engineering http://webdesign.danols.com/ Office: 613-817-6833 -- 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: Glad site is being brought back.
On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski wrote: > Please disregard this message, it was meant as a reply to a thread not a new > thread. > > -Original Message- From: Daniel Sokolowski > Sent: Wednesday, May 30, 2012 12:35 PM > To: Django developers > Subject: Glad site is being brought back. > > > I was just about to post a public message to Simon Willison urging him > to shut it down or fix the site when I found this thread. > > I wish to say thank you and am very grateful that you are fixing and > bringing the service back. > > On unrelated note would it be possible to change my username on the > site from: djangopeople.net/danols/ to djangopeople.net/ > danielsokolowski/ ? As announced on the Django weblog, people.djangoproject.com is live :) The code currently lives on my github account [0]. Feel free to submit issues and pull requests if you have ideas for improvements on the site. I'll look at renaming usernames, in the meantime if you need anything custom just get in touch privately. Bruno [0] https://github.com/brutasse/djangopeople -- 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: Draft branch: Swappable User models in contrib.auth
On Jun 6, 9:20 am, Russell Keith-Magee
wrote:
> wrote:
> > Understood & agreed (the "this model is dynamic made explicit" part
> > seems really important specifically).
>
> > I am afraid of the hard-coding of meta.swappable must be 'SOME_VAR'
> > which then references settings.SOME_VAR, and that this is made part of
> > the public API by the error messages. I would imagine that after app-
> > loading refactor one would make the swappable an app-level constant,
> > but the use of settings.AUTH_USER_MODEL directly in the code makes
> > this change backwards incompatible. Any chance of making what the
> > "swappable" contains more abstract? Something like suggesting making
> > foreign keys point to auth_user_ref() instead of
> > settings.AUTH_USER_MODEL.
>
> > Another idea would be to change the "swappable" to contain a method
> > reference, and then hint in the foreign key error message that "point
> > to User._meta.swappable() instead". (Or, make that Model property, so
> > that you could say to point to User.swapped_by instead, and
> > User.swapped_by would contain the real reference by checking where
> > User._meta.swappable points to).
>
> I can see the problem you're driving at, but I'm not sure it will
> actually be a problem in practice.
>
> Of course, it's impossible to know for sure without knowing the final
> App-refactor API, but based on the most recent discussions, the idea
> is to define a class that defines the App. I imagine that swappable
> models would be a part of this definition -- something like:
>
> auth_app = App(
> …
> swappable_models = {
> 'User': 'myauth.MyUser'
> })
>
> The exact syntax may be different, but the point should be clear --
> the App provides the point where the substituted User model can be
> configured, replacing the need for an AUTH_USER_MODEL setting.
>
> If this is the case, the requirement for "Meta: swappable" reduces
> from needing to name a specific setting, to just providing a boolean
> that defines the fact that the App is allowed to accept overrides.
> Conveniently, 'AUTH_USER_MODEL' (or any other string value) evaluates
> as True, so AUTH_USER_MODEL will be a slightly non-sensical value, but
> a perfectly legal on. It also means that the app can exist in both
> worlds (a settings-overridden model, and an App-defintion overridden
> model. There's some prioritisation logic required there, but thats a
> relatively minor detail). Long term, the syntax can reduce to 'class
> Meta: swappable=True'.
There is still something to not like about the "swappable is a
settings variable" system. Specifically, I am afraid of the fact that
the settings.AUTH_USER_MODULE will be spread all over user code, and
will thus be hard to deprecate. In addition, there is the possibility
some users might want to use another system than settings (like Andrew
Ingram's mention of Oscar). Maybe the settings variable is the
simplest thing that works.
Still, yet another API idea:
class SwappableUser(models.Model):
class Meta:
swappable = somemethod
# for example "lambda: getattr(settings, 'AUTH_USER_MODULE')
class User(models.Model):
class Meta:
swaps = 'auth.SwappableUser'
class AdvancedUser(models.Model):
class Meta:
swaps = 'auth.SwappableUser'
in settings.py:
AUTH_USER_MODULE = 'auth.AdvancedUser'
Then, Model.__new__ will replace the SwappableUser class with the
swapped in class. The 'swappable' in model.Meta tells which concrete
model implementation to use. The "swaps" argument tells that this
model is meant as a swap-in for 'auth.SwappableUser'. The "swap-in"
models would be directly usable only when they happen to be configured
to be the chosen swap-in model (thus, ForeignKey(User) would still
work as long as the AUTH_USER_MODULE would be set to 'auth.User'). If
trying to use a swap-in model which isn't chosen, you would get a
validation error.
The user could use SwappableUser with the knowledge (through naming)
that it might be something else than the default user model. This
would be the user code:
from django.contrib.auth.models import SwappableUser
class MyObj(models.Model):
user = models.ForeignKey(SwappableUser)
> > As for the User model as an ORM object - what lookups can be assumed
> > to exist? It seems the only requirement is that it has a numeric
> > primary key called 'id', otherwise there isn't anything that can be
> > assumed of it?
> However, if your requirement is to work with Admin, there are a couple
> more requirements. I *think* the minimum requirement is a definition
> for the following:
>
> * get_full_name
> * get_short_name
> * __unicode__
> * has_perm
> * has_module_perms
> * is_staff
> * is_active
What is the format of "perm" for has_perm? I guess it is the
app_label.permission_code, instead of "write", "modify" etc. Maybe
there is no way to change this now, but the app_label.permission_code
will make it somewhat hard to write generic "this user has view
permissions to all o
class based views and decorators: the usual pet peeves
Hi all, As a web developer primarily using django, i've been pleasantly surprised by the obvious advantages of using class based views, whenever they are applicable. So far they don't always seem to offer the most elegant solution for a specific problem, but obviously i simply use view functions in those cases. My main issue with class based views at this point (in which im obviously not alone), is the way they interact with view decorators. The best generally accepted way of doing this as far as i've seen involves implementing the dispatch(), which usually only calls its super(), and using the method_decorator()ed version of the view decorator on it. While this solution isn't particularly complicated, it seems overly un-pythonic, and a major step back in readability and elegance from the way they used to work, and still work for function based views. Recently i've written a very simple patch function, that simply takes a view decorator, and returns a new version of the decorator, capable to be used both on a view function, or a view class. While i would by no means suggest that this should be the exact way this issue should be addressed, i think it clearly shows that making decorators work "the way they should" (as in: similar in readability to what we're used to) is actually not that difficult. Personally i plan to further develop and use this patch in the projects i'm working on, but i would be more than interested to hear what everyone else's thoughts on this are. It may be worth mentioning that class decorators are not support in python 2.5 and older, in which case the patched decorator could still be used on a view function anyway the following code should demonstrate what i'm talking about here: from django.utils.decorators import method_decorator from inspect import isfunction class _cbv_decorate(object): def __init__(self, dec): self.dec = method_decorator(dec) def __call__(self, obj): obj.dispatch = self.dec(obj.dispatch) return obj def patch_view_decorator(dec): ''' patch a view decorator, so it works properly as a decorator on both class- and function based views ''' def _conditional(view): if isfunction(view): return dec(view) return _cbv_decorate(dec)(view) return _conditional # and this is how we patch a decorator from django.contrib.auth.decorators import login_required login_required = patch_view_decorator(login_required) # this is how we can write a traditional style decorator, while still making it compatible with a cbv @patch_view_decorator def foo(func): pass -- 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: Draft branch: Swappable User models in contrib.auth
On 4 June 2012 16:12, Russell Keith-Magee wrote:
> * The swapping mechanic is set up using a new Meta option on models
> called 'swappable' that defines the setting where an alternate model
> can be defined. Technically, the swappable option *could* be used for
> any model; however, I'm not proposing that we actually document this.
> I've implemented it as a generic approach purely to make the internals
> cleaner -- mostly to avoid needing to make references to auth.User in
> the model syncdb code, and to make testing possible (i.e., we can do
> validation tests on a dummy 'swappable' model, rather than trying to
> munge a validation test for auth.User specifically).
I like the idea of a 'swappable' option, but I can see some potential
issues with the implementation. I'm one of the developers of Oscar
(https://github.com/tangentlabs/django-oscar/) and providing a clean
method to for overriding models has been a major pain point. One of
our key requirements is that any model in Oscar may be overridden, to
that end every model has both abstract and concrete versions (much
like your implementation of AbstractBaseUser and User).
Our current way of handling overrides is for every reference to a
model in Oscar to use get_model rather than the explicit classname.
But this does end up causing some ugly things like this:
from oscar.apps.catalogue.abstract_models import AbstractProduct
class Product(AbstractProduct):
# stuff
from oscar.apps.catalogue.models import *
Issues:
1) The override model HAS to have the same name as the default model,
otherwise get_model('catalogue', 'Product') won't work.
2) We have to import all the remaining default models after we declare
our overrides. But this only works because Django's model metaclass
prevents the default Product replacing the one we've just defined. I
don't like this because it's a little bit magic.
3) You have to remove Oscar's version of the app from INSTALLED_APPS
and replace it with your own. Actually, technically you don't. If you
leave Oscar's app installed but put your own one ('foo.catalogue') in
front of it, you can even get rid of the nasty import * thing - but
again, more magic. (Aside: you can actually use this approach already
to override Django's User model, because the metaclass means any
references to Django's User will be replaced with references to your
own. )
I had investigated using a class decorator to handle overrides:
@replace_model('catalogue.Product')
class MyProduct(AbstractProduct):
# foo
But this got seriously complicated because the metaclass modifies the
class before the decorator can be applied, so I was looking into ways
to sever all the ties with the app cache before I went insane and gave
up.
Back to my main points... Your swappable option would solve quite a
lot, in the case of the User model it's ideal. But I'm concerned that
if people start using it more widely we'd end up having dozens of new
settings that would get quite silly in the case of a large project
like Oscar. I think it's important that overrides can be defined in
the settings file, but I'd also like to see it possible at model
definition time, either using a decorator (like above) or a Meta
option like 'replaces'. The risk, of course, is that it means any
third-party app could override any other model without you necessarily
being aware of it, not sure how this would be mitigated.
If I've not made much sense let me know, I've always found it hard to
articulate on this particular topic.
Regards,
Andrew Ingram
--
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: ModelForm enforces its version of save_m2m
Thanks for answering. It's "funny code" but it works indeed. Thanks again -- 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.com/d/msg/django-developers/-/2_4X_NFZmP8J. 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.
