The really quick turn around on tickets and pull requests is largely thanks to the Django Fellow, who is paid to manage the community. The last two or three releases have been on time because of the Fellow. The Fellow is funded via Django Software Foundation fundraising activities.
If your company is deriving financial benefit from using Django, consider asking your company to sponsor the fellowship program, so that we can ensure that bugs are getting fixed, releases are happening on time, and security releases are being processed as a priority.
I just started watching videos from this year's PyCon Australia [0]. Russell Keith-Magee, a core Django developer, gave an interesting talk called "Money, Money, Money - Writing software in a rich (wo)man's world" [1].
I love open source software, and I want to see more high-quality open source. I want to see established projects like Django continue to thrive. If you're curious about how funding impacts the quality of open source projects, you might want to check out Russell's talk.
It's baffling that such a huge project, used by thousands of companies including at least one billion dollar unicorn, have such a hard time finding money to fund only one single developer. As a solo owner and happy Django user, I've donated what I could and encouraged others to do so but would love to find a solution to entice larger businesses to donate regularly.
The Django Software Foundation has just hired a part time person to organise fundraising [0]. There is also discussion happening around the community about trying to find a sustainable way of funding open source projects and Django in particular.
Part of the problem is that it's hard to get companies to "donate" money. If they can purchase something like "support" or something else tangible, or "sponsorship" out of their advertising budgets, there may be more opportunities of gaining funding.
Thank you for donating though! Django gets a lot of their money from regular developers' pockets. I, personally, feel that bigger companies using Django to generate lots of revenue should be contributing a greater portion to support the stack that supports them.
Their need to "buy" something is the crucial point; donations fall in a totally different "account" with distinct rules. Sponsorships may be the ticket but you need to actively reach then as they won't come spontaneously (I think specifically of "that" unicorn :))
Not sure about support, maybe better to leave that to the myriad of contractors that form Django's ecosystem.
Maybe I do not know some important details, but why DSF (Django Software Foundation), does not do Django consulting in the first place. They very highly likely can do the best Django consulting in the world.
Secondly, maybe DSF could bake some great products for/from Django? The first ideas I have is Django specific, and user friendly:
- PaaS;
- analytics (as in 'new relic');
- crash and performance logging (as in 'sentry' and/or 'opbeat')
- CI;
DSF can just simply make business, by making great infrastructure stack around Django.
It's important to remember that the DSF is a non-profit foundation registered under US laws, which restrict what it can do. Many types of "just act like a business and sell things" ideas are automatically illegal for a non-profit foundation.
We need to be communicating this to them, quantifying how their business could potentially be doing better, and offering products that they can spend money on. It's that last part that I think most OSS projects are having difficulty with.
Yeah I understand it's not as easy as i'm suggesting and I have no idea how you guys manage to do as you do even :).
I'm wondering (and of course I know little about this) if it would work doing things like:
- community voting on the direction of the project or new features to be added and the top 5 get selected if there hits say 50k votes.
- costs say 2-3 dollars to cast a vote. But if it's enough cash it means it won't dictate the direction of django by money or businesses and some of the cash can be spent elsewhere not just on those top 5.
So a feature could be something like "seamless upgrading from 1.8 to 1.9" which businesses might want or be willing to pay for.
What do you envision the solution looking like? A list of projects, with their updated runway, yearly budget, technology category and subcategory? Maybe create a watch list too and send notifications when the combination of their runway, yearly budget, and rate of donations reaches a critical point of becoming unsustainable. You can also have people give a range of what they'd be comfortable donating. When the project comes to a critical point, the first line of defense is to send notifications to larger businesses and as a project becomes more in danger the notifications get sent down the line to the people whom have smaller budgets.
Before anyone says something about Django not being hip enough for realtime stuff, just know that you can layer Pushpin (http://pushpin.org) in front of it. This may sound like a bandage but it's actually good design, regardless of programming language.
Andrew Godwin (the author of django migrations and south before that) is working on something he calls Django Channels http://channels.readthedocs.org/en/latest/ . The aim is to bring it into core (possibly for 1.10), which will allow real time features.
The traditional request/response cycle will then just become producers and consumers of a "request" channel.
I'm a big fan of the design of pushpin - it's a really elegant solution for adding real-time features to frameworks like Django. I don't think it feels like a band-aid at all: for most web programming tasks, I'd much rather think in terms of a standard request/response cycle - it makes scaling with a shared-nothing architecture much easier to reason about.
I didn't hear about Pushpin before, looks like a solid product, will definitely look into it. I'm not sure if that's a valid question, but how does the Pushpin compare to something like SwampDragon (http://swampdragon.net/), besides not being tied to Django?
SwampDragon is a more comprehensive solution. It comes with a JS client and lets you define data models. Pushpin is lower level. It has no client protocol nor client library and handles various push primitives on behalf of the backend.
If you want to add realtime endpoints to an existing Django project, or if you want to build an API, then Pushpin may be preferable. SwampDragan may be preferable for new, non-API projects.
It might be cool to see the two projects integrate somehow, since they actually sit at different levels in the stack. There could be value in SwampDragon being able to delegate push responsibility to Pushpin.
It's gevent based and supports websockets and long-polling, by design it integrates with any kind of application for real-time broadcasts, be it django, php, cron scripts etc.
I haven't tried Pushpin yet, but we're using the Nginx push stream module on https://botbot.me in a similar manner. It acts as a reverse proxy to the Django app and also handles the realtime connections.
I upgraded from hstore a couple days ago. I expected it would take me a couple days, but it only took two or three hours. I basically just had to replace the field in the model, and was surprised to see the test suite passing. But it turns out that all of the application code just magically worked as is. And it's also a security win since you needed to be a Postgres superuser to install hstore.
If you are deploying a new django project, let me suggest hendrix (twisted + django) as your WSGI publisher.
hendrix makes concurrency simple, fun, and fast using Twisted, which is battle-tested and experiencing an amazing renaissance of young talent (as evidenced by the amazing vibes in the Twisted room at the PyCon sprints).
Download the tarball, untar it, make a symlink from inside your project dir to the "django" subdir. If you want to try another version, you just change the symlink to point to the other version. If you are curious which version you're running, you can just do a "ls -l" in the project dir. That's it.
I just got around to skimming the release notes, and I'm curious about running tests in parallel. I'm looking forward to upgrading, and seeing if this has a meaningful impact on my tests. I don't have a large number of tests yet; my project runs its full test suite in ~10 seconds at the moment. But I'm well aware this should grow significantly as my project matures.
Does anyone have any sense yet of how this affects the speed of the test suite in your real-world projects?
Massive speedups once you get to thousands of tests. We 12 minute runs for the 3 apps that are part of a release. When we went parallel it reduced it by 1/6 (6 test processes).
Of course, we also had some slow tests we rewrote and had to fix some tests that did not play nice concurrently. But it was well worth it.
I don't think you'll see a big benefit for a current 10-second run because of fixed cost of startup is some of that. But running tests in parallel may reveal some bad testing practices: leaving data behind or improper mocking that cause tests to fail in parallel. Fixing all that once you get to a massive set of tests is really painful and slow becuase you have to fix them ALL before switching your testing config. So that might be a benefit to turning it on soon and growing your tests already in an parallel environment.
Thanks for the thoughtful response. I appreciate the perspective on what it means for large test suites, and why it's beneficial to think about this in early development stages as well.
Expanding a bit: the plan is that 2.0 just switches us to a new versioning system. The tl;dr is:
Versions start going 2.0, 2.1, 2.2, then 3.0, 3.1, 3.2, then 4.0, 4.1, etc.
Every X.2 is a long-term support release.
The deprecation cycle gets tweaked so that if you're on, say, 2.2 LTS and your codebase runs with no deprecation warnings, then you'll be able to just run as-is on 3.2 LTS. You can then clean up any deprecation warnings on 3.2, and you'd be good to go for 4.2 LTS, etc.
No, not really. Django is moving to an "almost semver" versioning system. The X.0 releases will be when deprecated features are actually removed.
There are still some big ticket features that various people want to work on. These get released as they become ready. There may be some feature that is targeted for 2.0, but we won't know what until after 1.11.
Not looking to start a fanboy-war here; but i would like to hear some opinions. If you were to start a new small to medium sized web app today, would choose Ruby on Rails or Django?
I don't think this is really the right medium to ask that question. You'll find certain topics (Golang, Django, Unicorns) get up voted heavily on Hacker news and I think this indicates a bias that'll hurt discussions like yours.
That said I'll take a stab with it, as I've worked with both. First off they're both MVC frameworks that prioritize a fast, convention-first, development cycle. They both are very well proven, they both have great documentation, and they both have a large number of resources detailing nearly every aspect of their deployment.
So for me it is really a question of these three things:
* what your team is used to
* what resources (capital to buy talent if need be, time to invest in research, etc.) are available to you
* what edge-cases your app might come across over the development cycle (do you need real-time features? might you use a niche data-store? do you have to connect with particular third-party services?)
For each of those points you need to do some planning and decide what the answer if for your team. I believe if you have a grasp on this the answer will be some what evident to you. If it's not, then I think you can just flip a coin because it won't matter to you.
I'll give my stock response when this question comes out: the reason why I chose Django back in the day (we are talking pre 1.0) was because it stuck with the Python philosophies of configuration-over-convention and "principle of least surprise".
It made debugging issues much easier than in the equivalent Ruby on Rails project (I tried to build the same proof-of-concept using both frameworks.) When something broke in Django I could usually just follow the code to find what was wrong. With RoR sometimes I would put stuff in some place, expect the framework to pick it up (convention-over-configuration) and the code wouldn't work. Much head scratching ensued.
Right - if you're not familiar with either language, then have a look. For me, at least, I could never really wrap my head around some Rubyisms. Python on the other hand, just "made sense" to the way my brain works. I can parse Ruby mentally, it just takes more effort.
If you're familiar with both, and have no clear preference, the question becomes a lot less clear-cut.
I mostly agree. At this point they are both excellent frameworks with all similar features. Django has a really nice admin out of the box that some people love.
Rails is built with a "convention over configuration" philosophy. Rails apps tend to look similar whereas Django apps tend to be setup in a number of different ways. The downside of Rail's "convention over configuration" setup is that devs can get things up and running fast and then get frustrated and lost if something breaks....but it's really not that hard to dig around the code. With Django new devs get lost first and figure everything out. After a few months of heavy use and breaking things you won't notice much of a difference between the two. I find rails a bit easier to work with but I like python so I use django/flask.
I'd choose Django hands down between the two, but I'd pick Flask in the case of a smaller or less generically-cms app.
With that said, if you want something up & running asap, pick whatever you're good with and if you want to learn, pick whatever you didn't use before. Django and RoR are comparable.
I'm shocked, frankly, at how lousy both are out-of-the-box. I just don't get why a simple CRUD app (which many/most apps are) has to be so difficult. I had trouble figuring out how to do email login on Django and just gave up. At first, Rails seems like it's going to be a lot better. I don't care for generating files. Don't like TDD. And found the migrations very confusing (if I make a typo in a field name, I delete the whole project and start over).
I can't believe this is the current state of web app development. I know everyone's moved on to Node and Angular, but, c'mon!
So that's it? I've never seen that before. Everything I saw seemed more complicated from installing various auth addons to multi-file edits and finger-crossing.
And I don't see how assertions like this can be made: "This will usually be a username of some kind, but it can also be an email address"
Except for HN, Twitter & Reddit, are there any services that don't use email for login?
> Except for HN, Twitter & Reddit, are there any services that don't use email for login?
I guess sites that use the username as a form of identity within a site. Email address usernames are just identifiers and contact information, without really being linked to an identity.
I would think if auth was being written from scratch it'd probably default to email based usernames. That ship has sailed though.
But it shouldn't have sailed. Frameworks need to keep up with the times. That should be a benefit of frameworks. Should be possible while preserving backwards compatibility.
Note that database migrations weren't part of Django until 1.7, before that they were provided by an external app (South).
Which meant that Django's database models couldn't migrate.
Even now, there is no real way to start with Django's own User model and switch your project over to a custom one later (because you'd have many database tables with foreign keys to the Django one). The current recommendation is to start new projects with a custom User model always.
I think this is more a flaw of the authoritarian nature of larger web frameworks. They can't cater to every use case and have to be opinionated in certain areas.
In Django's case I would say their Authentication model was an opinionated choice that has since become a major staple of Django. Many frameworks will not include default ORM-models and will instead defer to the user to implement their own authentication scheme.
Personally I disagree with this choice, I think database schemas have to be flexible and an in-framework authentication setup will only encourage users to lean more on the framework even when it is working against them. I've burned plenty of hours in Django trying to work / extend the authentication model. While I have no doubt much of this was due to my inexperience with Django, there is a certain responsibility with having a framework used by many beginners who will struggle and perhaps pick up bad habits (like expecting your web framework to automagically solve everything) if you do not design it for them.
Overall I think Django is awesome. But it's not for every use-case, or every developer. About a year ago I moved over to NodeJS professionaly, some day I will perhaps go back but have yet to have any significant reason to do so.
Unfortunately it looks like you hit a bit of a sore spot with regards to django auth. There isn't a good out of the box solution for email based usernames. There are patterns available, and the "swappable" user framework is there to allow email based usernames. But an email based model isn't available. I'm fairly sure there are tickets or ideas to make this happen, but we're not there yet.
Django really is quick and easy to get going though. If you can make your way past the email based usernames, I think you'd find a really capable and easy system waiting for you.
I think a bigger issue with regards to usernames and email is the fact that neither are titlecased before getting indexed. I get that there are certain legacy considerations or whatever, but it really seems like there should at least be a note in the documentation about this given the massive clusterfuck that would potentially ensue should someone not figure this out before launching.
Yeah, I actually hadn't seen that, but I know there are also longstanding tickets for this. I actually don't like the solutions in those threads, I think better to just add an extra field to the models, so have something like 'db_email' and 'display_email'. I realize you can do this with a functional index or whatever, but I think that's actually kind of hacky given the lack of ORM support for functional indexes.
My big issue with the current state though is that if you're relying on usernames or email addresses being unique then you're potentially opening yourself up to all sorts of security issues without realizing it.
FWIW I agree the solutions in that thread aren't good enough, especially since most of them are postgres specific. Now that migrations can be shipped with contrib.auth, a better solution might be possible.
I'd probably prefer a functional unique index since it would be easier to maintain (rather than duplicate fields). We just need to get expression support into indexes.
Well, I hear there's this expressions API and that now it's possible to use them during the initial creation/save of an object... maybe there's some normalization people could do with that :)
Do you know how well cookiecutter-django [0] handles email logins? I've been meaning to play around with cookiecutter, but I haven't started a new project recently. Cookiecutter uses django-allauth [1], which seems to offer email login methods, from what I see in a cursory look at the docs [2].
It's comforting to know that I'm not the only one who struggled to get email-based authentication working in Django. It had me feeling totally incompentent a few weeks ago and I ended up implementing something very hackish to set the username equal to the email address.
For me this is the wrong question to start with. The right question is what language do you want to work in first. Then determine which framework for that language best suits your needs.
I would say if you anticipate any sort of data science and machine learning potential in your application, then you should choose Django (Python) because you'll be in the home turf for this sort of work and you won't have to deal with language context switching... But this is a big if and may not be worth considering.
If your app has data of a large enough size for serious analysis, shouldn't you be building a data warehouse separately and performing analysis on that?
(scientific) Python is definitely better at stats out of the box than Ruby is though.
I've dabbled with both, and they suffer from the same kind of problem that all frameworks on top of dynamic languages suffer from. You essentially have to do all the checks that the compiler /should/ do for you, by using unit tests. That gets old fast. Also, on large code bases, I now prefer having real refactoring support.
I'd rather pick something on top of a compiler that is not brain dead.
If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.
I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.
I've dabbled with both, and they suffer from the same kind of problem that all frameworks on top of dynamic languages suffer from. You essentially have to do all the checks that the compiler /should/ do for you, by using unit tests. Also, on large code bases, I now prefer having real refactoring support.
I'd rather pick something on top of a compiler that is not brain dead.
If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.
I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.
This is, of course, why nobody has ever bothered developing a unit-testing framework for a statically-typed language, and why it would have been impossible for the idea of automated refactorings to have originated in a dynamically-typed language.
I'm just speaking from the practical experience I have.
It's just that in static languages, you write unit tests more around business functionality. In dynamic ones you end up writing unit tests essentially for typing and stuff like that. And, you know, you have tooling so you can actually perform the refactorings at scale across the code base. Like real tools, that the rest of your team know how to use, and your business can hire another person from the same hemisphere to work with after you've moved on.
The tooling around static languages is generally stronger. I've written very similar types of code in both Java and Python, and hands down, I've found it easier to develop and maintain in big code in Java.
I still script quick stuff up in python for personal use.
The really quick turn around on tickets and pull requests is largely thanks to the Django Fellow, who is paid to manage the community. The last two or three releases have been on time because of the Fellow. The Fellow is funded via Django Software Foundation fundraising activities.
If your company is deriving financial benefit from using Django, consider asking your company to sponsor the fellowship program, so that we can ensure that bugs are getting fixed, releases are happening on time, and security releases are being processed as a priority.
(Disclaimer: core member).