Django's auth system is not that hard to hack on if you need to - in most cases you just need to write a custom backend and implement a few methods on it. It's certainly comparable to writing your own, or downloading something and integrating it.
But now you have an auth system that's tightly coupled to SQLAlchemy. How is that different from the regular system, other than you're using SQLAlchemy rather than Django's ORM?
I'm also finding it hard to think of a use case where you need to authenticate 100 users at once, so your initial rationale (100 separate updates) doesn't really work. Surely you'd use a different tool to populate your database, but Django's ORM for day to day stuff?
I'd say that's better than anything hardcoded to a fixed database schema. There's a whole world of development that has no interest in using a mediocre, off the shelf database schema in lieu of one that is designed exactly for the problem at hand.
I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand.
Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopped trying to figure out what was going on when I realised that
headers = remember(request, login)
actually returns the raw headers as a list of strings, and you need to feed them manually back into the response.
When I look at django apps they are often similarly hideous to me. (edit: such as - when hundreds of objects are pulled into memory, then filtered further, or processed one at a time, when the entire thing could be done in one query. They'll do this not only because the Django ORM isn't capable enough to do the work out on the query side, but also because the programmer isn't SQL-aware enough to know that's even how it should be done. Django's lack of capability is matched by the developers lack of awareness, and the conclusion for such a developer is "django works great!" This is why SQLAlchemy users get annoyed by Django and Django users get annoyed by SQLAlchemy. There are two totally different ways of looking at problems going on).
This whole thing is about where you're coming from and what software development traditions you subscribe to. We know full well django isn't going anywhere and you can rebut all you want, the alternatives aren't going away either.
Well, when I see code like that, I see lots of moving parts, all with their own weird API, interacting in odd ways. You just have to know that thing X takes a string, an object and a callback function, and there are twenty thing Xs, not five.
Complexity breeds bugs like rabbits; if you can't look at something and understand what's going on (potentially drilling down into an abstraction or two), then it's going to be a maintenance nightmare.
If you can come up with something that's easy to use and powerful, like the declarative_base stuff in SQLAlchemy over the top of the Mapper/Relationship, then I'm all ears - but if complexity is the price that I have to pay for that then it's not an easy tradeoff to make, and in a lot of cases you're better off with the easier, worser solution.
A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly? ie. so that all of the fancy Django manage commands work. I'm assuming a fair bit, but it might be a good way to get some sort of help as far as SQLAlchemy goes. Or you might be happy to continue forging ahead solo, I don't know. Just a thought ;)
> A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly?
There is a version of this I have in mind that would take at least 6-8 weeks of pretty solid developer time. A new layer would be built on top of SQLAlchemy ORM that would look just like Django mappings/QuerySet. The mappings wouldn't be too difficult, QuerySet maybe a little more.
The advantage to that approach would be that existing Django mappings and QuerySet code could be reused in the context of a SQLAlchemy session conversation, that is, the unit of work/identity map paradigms would be brought in. A lot of the "bolted-on/doesnt-really-work" code I see to approximate these features in a tool like JohnnyCache wouldn't be needed anymore.
I'm not sure that this really encompasses "manage" though, I'd have to increase my familiarity with that tool to know everything it does.
Well that's cause the Pyramid Auth API is admitted by the authors to be overly complex. They did a post mortem here and you can read about some of the mistakes they made when designing the API: http://plope.com/pyramid_auth_design_api_postmortem
The most relevant line to take away from their post mortem is this: "Unfortunately, when designing a framework, you get exactly one shot at creating "the right" API. In this case, we didn't."
So even with a decoupled API, if the design doesn't fit your needs or is too cumbersome to use, you will still need to find a third party solution or hack the core code. Both of which, as mentioned by others, are possible in Django.
Chris' perception of design errors aside, there is no reason a feasible auth system not tied to a specific persistence system can't be built. My usual way of proving this is by building one but I'm really at my max number of OSS projects to be maintaining.
I guess I'm not sure I understand what you're getting at here.
Django's auth system requires a backend to implement an API consisting of exactly two methods. One method is passed a set of credentials and returns something "User-ish" (i.e., possessing the attributes of a Django User object), the other is passed an ID and returns a "User-ish" object corresponding to that ID.
Neither of those methods requires the use of Django's ORM, or the use of a database, or really the use of any way to store data at all.
This means that how the backend stores data, and whether it stores data, is irrelevant; if you want to use a DB and SQLAlchemy to interact with it, you can and the auth system neither knows nor cares. You could, assuming a migration plan in place, switch away from the DB and away from SQLAlchemy and store user data in flat files if for some reason you really wanted to, and the auth system would not care and would not notice anything had changed.
I fail to see how anything would be gained by somehow forcing a store-agnostic data API into this picture as part of the auth system, when the auth system currently doesn't even care whether you're storing things.
