Feature request: make django.contrib a namespace package
When trying to fix ticket #14087, I got an idea on how to separate out all contrib apps. Make django.contrib a namespace package. Every django release just ship one more package which does not bundle any contrib apps. The other one just bundle latest stable versions of contrib apps. Thus contrib apps could be developed separately from django core, while django releases are still batteries included, and it might be a litter easier to develop an app to be included in django.contrib. -- 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: call_command; add *.pyc and *.pyo files to commands list
> I'm extremely strongly -1 on this. .pycs are a) an implementation detail, > b) not even remotely a security tool, c) really just ship your source, > having extra support for them is a waste of time IMO. agreed. > having extra support for them is a waste of time IMO. IMHO, no extra support for them is required. Simply add support for PEP 302 importers, Django will find management commands in pyc/pyo files. I improved patch for #14087 weeks ago, which add support for PEP 302 importers. I am just wondering why the core team did not even bother to review it. https://code.djangoproject.com/attachment/ticket/14087/zip_egg_fixed.4.diff -- 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: auth.User: The abstract base class idea
Maybe we could make every model pluggable. so User model could be defined like this: class User(models.Model): __mixins__ = load_available_mixins(settings.AUTH_MODEL_MIXINS) But AFAICS, Django will suffer from the same issue as PHP register_globals / Rails mass-assignment, because of ModelForm. and Django must provide schema migration tools. On 3月22日, 上午10时33分, Alex Ogier wrote: > I made a topic branch and refactored everything I thought was nicely > reusable from auth.User into abstract models in > django/contrib/auth/mixins.py. There are some good reusable pieces inside > auth.User, even if you want to entirely scrap Django's notion of identity > and the username and/or email fields. The change is transparent to Django's > test suite, and I did my best to leave the existing API identical. > > My hope is that we can make, for example, contrib.admin only dependent on a > class implementing PermissionsMixin. Whether we do late binding to > auth.User with some jiggery-poker as described in the recent auth.User > reboot thread, load time plugging into the auth.User inheritance list as I > proposed in the first email in this thread, or just punt on the whole thing > and ask people to implement their own concrete classes, I think the > refactoring is a nice backwards-compatible way to expose pieces of > auth.User for people to reuse and/or depend on. > > https://github.com/ogier/django/tree/auth-mixins > > Does anyone have any opinions? > > -Alex Ogier -- 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.
add support for PEP 302 importers
I am working on fixing #14087. I think the biggest problem is that django do not support PEP 302 importers. Also, because of this, tickets are marked as won't fix or fixed by introducing much more implementation detail. It is not hard to find many of them, #582 #596 #8238 #8280 #12206 #13587 #16718 #17331. #13334 might be the only exception. Add support for PEP 302 importers should fix most of them, if not all. -- 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: auth.user refactor: the profile aproach
django.contrib.auth.get_user already uses BACKEND_SESSION_KEY to
decide from which backend to get user object.
To support multiple user models, we can just change the
AUTHENTICATION_BACKENDS setting to a dict just as DATABASES.
AUTHENTICATION_BACKENDS = {
'default': {
'BACKEND': 'django.contrib.auth.backends.ModelBackend',
'MODEL': 'django.contrib.auth.models.User',
},
}
Instead of a single global USER_MODEL setting, each app should have
its own USER_MODEL settings, like ADMIN_USER_MODEL,
COMMENTS_USER_MODEL .
I do not like `ForeignKey(settings.ADMIN_USER_MODEL or
settings.USER_MODEL)` . I prefer a combination of solution 2a and 2b
to that.
On 4月4日, 上午5时51分, Alex Ogier wrote:
> Thanks for the response, Adrian.
>
> > 4. Third-party models should be changed to use something like "user =
> > UserField()", which would automatically create a foreign key to the
> > registered User model. If you change your registered User model after
> > you've created those third-party tables, you're in for trouble. Don't
> > do that.
>
> > 5. Django provides some generic APIs for getting at the registered
> > user. Example: a middleware that sets request.user based on the
> > current session.
>
> I think convenience methods are nice and all, but we should be careful of
> making "The Registered User(tm)" too much of a baked-in concept. Ian Lewis
> made a great point a few weeks ago: There are domains in which it is
> frankly inappropriate for various authenticated users to mix in the same
> database table with the same uniqueness constraints. Maybe you run a
> medical record management site, and some of your users are administrative
> staff and doctors, and some are patients. Sure, you could manage this by
> having a unified model containing everything, and carefully validating with
> an "is_doctor" field the way contrib.admin handles "is_admin," but it might
> be more appropriate to have separate models. It becomes much easier to
> express authorization constraints such as, "As a hospital administrator,
> Ms. Sally Johnson is authorized to view the patient list of Dr. John Smith,
> but *absolutely not* his record as a patient himself," or "Patients like
> Dr. John Smith can be authenticated via Facebook Connect, but doctors need
> to be authenticated via our internal LDAP." You can have login ModelForms
> for doctors that log in to doctor records and the Django admin site, and
> login ModelForms for patients that let them view their own records through
> the frontend.
>
> Obviously supporting multiple user models isn't something that should be a
> priority for Django, but locking people out of the choice seems unwise,
> when we can get the option "for free": just let authentication backends
> return any authenticated object at all to add as request.user. Python's
> duck typing will get you the rest of the way, except for those persnickety
> tables that absolutely must have a specific concrete table to foreignkey
> on. We already do something similar for AnonymousUsers, exposing a common
> interface at request.user that isn't backed up by the canonical User table.
> Generalizing that is A Good Idea in my opinion.
>
> Anyways I look forward to seeing how this progresses. I'd love to be a part
> of making this happen. Would you like me to turn my work on breaking up
> auth.User into reusable chunks into a ticket on trac? I think it makes
> sense to merge no matter what we decide on for specific settings and access
> mechanisms to developer-defined users.
>
> Best,
> Alex Ogier
--
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: auth.user refactor: the profile aproach
LazyForeignKey will not solve any problem that can't be solved now, and we have to introduce a new concept. It sounds like, when we encounted a hard problem, we give it a new name, instead of trying to solve it. Moreover, to support multiple user models, each app should be able to link to a different user model, LazyForeignKey can't be any help. Maybe the only way to solve this is to add a schema migration tool. When schema migration tool found a ForeignKey link to a different model than before, it raises a error, then I know there is something wrong. On Apr 5, 8:45 am, Russell Keith-Magee wrote: > On 05/04/2012, at 12:20 AM, Adrian Holovaty wrote: > > > > > > > > > > > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss > > wrote: > >> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > >> My point is that there is nothing about this problem that is unique to > >> User. > >> Django's own codebase contains another example of exactly the same pattern > >> -- Comments. > > >> As the original author and designer of that pattern, I should probably > >> point > >> out that I now think it's a mistake. Have you actually tried using it? It > >> doesn't really work very well. Every time I've introduced any sort of > >> "swappable model" mechanism I've come to regret it. > > > Totally agree with Jacob here, plus Tai's comment that "There is such > > a thing as too generic." We've made the mistake of making things too > > generic in the past, and it's kind of infuriating in retrospect, both > > philosophically and in terms of code maintenance/understanding. > > (django/utils/tree.py, anyone??) > > > I think our policy should be: make the simplest thing that can > > possibly work for a narrowly-tailored use case, then make things more > > generic *slowly* if there's a demand. No need to be an Architecture > > Astronaut. > > Certainly agreed that astronauting is a bad thing. > > However, I would like to draw attention to one particular benefit of the > generic solution (other than being generic): > > Once we make User swappable, every app with a model that has a ForeignKey to > User will need to be updated. This can be done slowly; existing projects that > use auth.User will continue to work. However there won't be any real alert to > the fact that the app requires updating until you try to swap out User and > things start to break. This breakage will be somewhat unpredictable -- you'll > just be observing side effect errors as a result of a non-existent (or empty) > auth_user table. > > Under the approach I described, User will be marked (in the Meta object) as > swappable, and ForeignKey(User) will be a hard link to a swapapble model, > which is something we can catch as a validation warning, providing a cue to > developers that there are apps in their project that may need to be updated. > And if there is a ForeignKey(User) and settings.USER_MODEL *isn't* User, then > we can raise an validation error, because we know that this app won't work. > > Even if we don't implement a fully generic solution, I think this property of > the generic approach is worth preserving. > > 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: auth.user refactor: the profile aproach
I think we need three different kinds of models, Identity, Profile and Authentication Info. * The Identity model should have all fields shared by many apps. * Each app can have its own Profile model. If a field is not shared with other apps, just put it in the Profile model. * Since password is never used after an user is authenticated, authentication backends should declare fields like passwords, OpenID credentials in their own Authentication Info models. Having any default fields in the Identity model is not appropriate, most likely we will find a use case in which a certain field is not needed. But if the Identity model has only PK field, data synchronization will be a big problem, for each field shared by multiple apps, you need a signal, and suppose you have 20 models and they have 3 fields in common, when you changed these 3 fields in one object, you will have another 19 objects saved three times each. Furthurmore, a project may need more than one Identity model. Both LazyForeignKey and multiple Profile solution do not address this problem. Since any app may have its own APP_IDENTITY_MODEL setting, the unpredictable problem if APP_IDENTITY_MODEL changed after initial syncdb, is unavoidable. IMO, this problem can only be solved schema migration tool and should be solved by schema migration tool. If Django ORM assumes that schema would be changed overtime, schema migration should not be an optional part of it. On Apr 6, 9:52 am, Tai Lee wrote: > Thanks Anssi, but I think the interface contract for a pluggable app *should* > be on the pluggable app's profile, instead of relying on an assumption that > developers will have created a user model that is duck typed to suit every > pluggable app installed in the project (which might not be practical or even > possible). > > For the sake of avoiding duplication, which could be managed with signals and > the save() method of a project level profile, you potentially overload fields > that are not analogous across pluggable apps by sharing a single namespace. > E.g. is_active for the admin may not mean is_active for app2 or app3. > > Jacob, by having to define a minimum set of fields that users must implement > in their swappable User model to support contrib apps like the admin, don't > we end up exactly where we are now? Isn't this exactly what we have already? > > The only difference I see then is that the interface would be defined in docs > instead of a model and re-implemented by developers for every project, and > pluggable apps will often require a schema migration on the swapped-in > project level User model when adding a pluggable app to an established > project. > > In my ideal scenario, User would be a glue model with just a PK, and maybe > some convenience methods. AdminProfile would not have username or password > fields, but would have is_active, is_superuser, and maybe optionally a name, > etc. > > Developers would need to create at least one model in their project, which > would be a subclass of BaseAuthModel in most cases, which stores > authentication credentials. > > They would also need to create an auth backend, which would be a subclass of > BaseAuthBackend in most cases. > > Pluggable apps could also define auth models and backends if they require > specific auth to function (e.g. an app that adds twitter integration.) > > Then people could login to the admin and any other pluggable apps using > whatever credentials and authentication system they like (username/email and > password, twitter, Facebook, openid, etc.) Developers wouldn't need to > implement a minimal set of fields or do a database schema migration to > support or install any pluggable apps. > > If app1 or app2 require access to an email address (for example), their > profiles should have a required email field. It should be up to the project > developer to make sure that an email address is set when creating an app1 or > app2 profile for a User, and synchronizing them between app1 and app2 (if > appropriate). > > I think the data duplication issue is much easier for project developers to > manage explicitly without resorting to magic and assumptions than sharing or > combining namespaces for profile data, doing database scheme migrations, and > duck typing a single model for use with multiple pluggable apps. > > Cheers. > Tai. > > On 06/04/2012, at 7:42 AM, Anssi Kääriäinen wrote: > > > > > > > > > On Apr 5, 11:29 pm, Tai Lee wrote: > >> But I still don't see how a swapped in `User` model which *has* to behave > >> in a specified way so that it can work with the Django admin and any other > >> pluggable apps that might have special requirements, is any better than > >> simply allowing the admin and other pluggable apps to have their profile > >> and authentication needs self-contained? > > >> If Django's `User` model was just a stub (without even username and > >> password fields), and Django shipped with an abstract `BaseAuth
Re: Django is not a serious framework, really
The document clearly states that "You'll see a message for each database table it creates". I guess Jason Ma had a hard time reading the document because it is written in English. Native Chinese speakers who are not quite familiar with English will feel desperate when they had to read serveral pages of document in English. Just imagine how desperate will you be if you have to read pages of document in Chinese when you just learned Ni Hao. Django is getting more and more popular in China recently. More and more people there are asking questions like how to do this or that in Django, most of the time, it is just because it is too hard for them to understand the document on their own. I propose that Django has a Chinese translation of its document. Sure, there is a huge amount of work. If core team decides to work on this, I would like to help. Disclaimer: I do not know Jason Ma, I guess he is a Native Chinese speaker because I googled his email found his email appears on some Chinese website. On 4月11日, 下午9时29分, Aymeric Augustin wrote: > Hi Jason, > > Le 11 avril 2012 14:10, Jason Ma a écrit : > > > I heavily doubted that whether the writers have tested that carefully. > > As one of the many people who replayed the tutorial from A to Z, > checked every little detail, updated screenshots, etc. before the > release of 1.4, I feel your feedback is rather unfair. > > > There are many people saying the Django is well-documented, do you > > still think it is true? > > Django's documentation assumes that the reader: > - has some familiarity with Python (e.g. knows what a __init__.py or a > *.pyc file is) > - is an autodidact and is able to investigate by himself when (s)he > deviates from the recommended path and encounters an unexpected > behavior (e.g. syncdb doesn't perform migrations). > > Honestly, if this doesn't match your expectations at all, then Django > might not be the right framework for you. > > I still believe our documentation compares favorably to most > open-source software entirely developed by volunteers in their free > time. > > Best regards, > > -- > Aymeric. -- 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.
Proposal: Add support for PEP 302 importers
Django makes assumptions about the filesystem layout of python packages here and there, and will silently skip any app which does not meet Django's assumptions without raise up any warning. I had been bitten by this many times before I learned that Django and Django apps should never be packaged as zip-archived eggs. IMHO, all these problems can be solved by adding support for PEP 302 importers. And I found that there are three different kinds of problems. 1. find submodules before importing the package: finding management commands 2. find submodules after importing the package: finding template tags and listing available database backends 3. find resource files after importing the package: template files, static files, fixtures and translation files Finding template tags in zip-archived eggs has already been solved by #13334. and I have been working on solve remaining problems in the past few months, and have all but 2 related regression tests passed, and code is now available on Github: https://github.com/bhuztez/django/compare/master...pep-302 How many tickets should I open on trac? a single ticket for all, or one ticket for each problem, or one ticket for each related parts of code which would be six or more? Any ideas? -- 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: Breaking out localflavor
> So for a namespace at django.contrib.localflavor.* I *think* that django > and django.contrib would both need to be namespace packages as well. > If i'm right about that > thenhttps://github.com/django/django/blob/master/django/__init__.py > will need to be moved to somewhere else as well. Yes, __init__.py need to be moved, but I'd like to see Django break out all contrib packages as namespace packages. On 8月17日, 上午6时21分, Donald Stufft wrote: > I could be wrong but offhand to make a namespace package you're > going to need to make a namespace package for everything above it. > > So for a namespace at django.contrib.localflavor.* I *think* that django > and django.contrib would both need to be namespace packages as well. > If i'm right about that > thenhttps://github.com/django/django/blob/master/django/__init__.py > will need to be moved to somewhere else as well. -- 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.
