 Thanks. Sorry for the slight delay. As I said, my name's Mark, and I'm here to talk about the anatomy of a Django project. It's listed as a novice talk, but really this is for anyone who's ever started a new Django project and not quite understood what was going on or come into an existing Django project and wondering what's going on. I'm the technical director of Cactus Consulting Group. We do Django-based consulting. I've started probably dozens of Django projects over my time there, and I've encountered code bases for a dozen more. I've seen a lot about how people like to set up their projects. I've seen things that work. I've seen things that don't work, and a lot of those ideas come from that. This is the central question that I want to answer today. What is a Django project? We talk about Django projects. We talk about Django apps. We talk about web apps. We talk about whiskey apps. We use a lot of terms without really well-defining them. I want to describe my thoughts on what a Django project is and let you guys decide that for yourself. Django applications are Django apps, like Lego bricks. They're supposed to be these pieces that compose a larger application. Some apps are very reusable. Some apps are not. Again, just like Legos. Apps don't usually run by themselves. Lego bricks aren't particularly interesting by themselves. They need to be assembled into something larger. They're assembled into projects. A Django project, as defined by the Django tutorial, is a set of configurations for a set of apps. Apps can be used in multiple projects. Projects can be comprised of multiple apps. This is the real high-level idea of what is a project and what is an app. When most people come to Django apps or Django projects, they begin with Start Project. Start Project looks like this. I'm going to start a new virtual environment. I'm going to install Django. I'm going to run Start Project. It's going to give me some stuff. This is the project, I guess. It's these files. It's an outer directory named for the name that I gave Start Project, a managed PY, and then an inner Python package. This directory is a Python package because it has an init. Somewhere in here is a Django project, or all of it is a Django project. Let's look at each one of these files and understand what they do and see what they mean. So, managed PY, if you've never looked at it, it's pretty simple. It doesn't really do much of anything. It sets a default for an environment variable, and then it calls a function called execute from command line which is built into Django. It looks much like of another file which we've already used, which is Django admin, which just calls execute from the command line without setting the environment variable. Without setting the default environment variable. So, if I had already set this environment variable, then I wouldn't need manage. Manage really isn't part of my project. It doesn't have any real configuration for the collection of apps that I'm using. It's just a shorthand for Django admin PY. So, it's pretty easy to get rid of manage. If you haven't seen this, this is awesome. Manage is not really that interesting. So, we're going to add the path of the project to our Python path. This is using virtualm wrapper, which again, if you haven't used virtualm wrapper, you should be using virtualm wrapper. We use two little hooks of virtualm wrapper, post activate, post deactivate to set the environment variable and then unset the environment variable. This is so I don't have to use the settings flag. And then just to make sure that it worked, I deactivate, reactivate the virtual environment, delete manage because I never wanted to use it and just run with Django admin. So, whatever a Django project is, even though the start project gave it to me, I would say manage is not part of it. So, let's continue on and dive into this, this my project package that we got. There's a settings PY. Well, one would guess that by the name of it, it is in fact a collection of settings for configuring a collection of Django apps. An interesting little note is that this comment, and this is generated by one six, as you can tell, is that there's a little comment says builds paths inside the project. And the path that it references is the parent parent. So, it's that outer directory where manage PY was. So, settings, at least in this comment string, things that manage was part of this project. But I deleted it. Some other files that are in here are urls PY. Again, this is based on one six. You don't need some of this in one seven. Admin goes away in one eight, you don't need patterns or patterns is deprecated. This is one six. And this is what your typical urls PY looks like. It's pretty straightforward, but it's kind of a mixture of configuration and code. It's directing urls to callables. That's what urls PY does. It delegates potentially that responsibility to other files. In this case, we include the urls from admin and route them to admin. So, this is sort of a configuration and we'll err on the side of saying that this is part of the project. The last file, other than the init, which is empty, is the whizgy PY file. This builds the actual WSGI application that you need to deploy on your favorite WSGI server. Again, it sets the environment variable. We've already set that at least in our local environment. If you're just using the default a whizgy application, you could say that this really isn't project specific. If you are using additional whizgy middleware, which would be an interesting thing to explore. I don't see very often. Then you could say this is really configuration. So, this is sort of part of the project. It's sort of part of the deployment process. So, those are all the files that start project gave me. I'm getting a little closer to understanding what a Django project is, what start project gives me. If we look back at the settings, we realize that the settings point to these other files. The settings points to the root URL configuration. It points to the WSGI application. So, the only file that really stands by itself in a Django project is the settings. This namespace that we created is my project package, bundles these files together. But here from these settings, it's clear that they do not have to be. This is a choice that Django made for me that I don't have to obey if I don't want. So, the settings file is really the heart or potentially the only thing that exists in a Django project. So, some questions that come up about settings, about projects. Where should my apps live? Should they live in this namespace? Where should additional templates live? What about static files? Should they live in here? Can my project have views? Can my project have models? I would say that they all have one kind of real answer and that is there is no such thing as a Django project. There's only settings files. And a single deployment may have multiple settings files. It probably has multiple settings files for different environments. Local development is not running the same settings as the production environment. So, to answer a lot of these questions kind of falls from this idea. Django projects don't exist. Because Django projects don't exist, if you want templates which aren't part of an app, you have to tell Django where they are. And you tell Django where templates live if they aren't in an app in template theirs. It's a setting. The same thing for static resources. If you want to reference static resources that don't live in an app, you have to tell Django where they are. And you tell them through the static file stirs. Whether or not apps should live inside this project namespace or not is entirely up to you as a Python or Django developer. You would use the same rules for however you would organize your application code. You can put them in the namespace. You cannot put them in the namespace. Some apps are reusable. Some apps are not. A better question is probably not whether they should live inside the project namespace, but whether they should live in the same repository at all. So, I want to show some alternate project layout configurations that I kind of made for fun. To really think about this idea or explore this concept that projects don't exist. Or that the project that you get from Start Project isn't the project that you have to use. This namespacing is totally optional. And you should use the facilities that Django gives you to organize your project in a way not at what makes sense to Django, but what makes sense to you. We're going to play. We're going to explore. If you didn't know, Start Project takes a little option called template. And you can point it to a path. That can be a file system path. That can be a zip file. It can be a remote URL. At Cactus, we have one. You can see it. It's open source for our project layout. And how we like to layout projects, our default salt deployment with fabric pieces and the apps that we like to use by default. And these projects that we're going to look at all follow this template. And so when you call Start Project, you give it a name. And that project name is replaced throughout. So here's the first one. So I like to call the app project layout. This replaces that inner project name space. Not with the project, but with an app. And by app, I mean something that's going to contain real business functionality, maybe models, maybe views. But more importantly, when I say app, I mean a Python package which must be added to the installed app setting. Because definitely by 1.7, models are no longer required. The only thing that defines an app is that it's in the installed app setting. An app is really not a thing. That's a different talk. I'll leave it for America to tell you why an app isn't a thing. So I like this idea of a layout because I see people do this a lot. They say, I want an app that sort of holds this logic for my site. But I already used the cool name that I thought of. Naming things is hard. So I name the project, my fancy project. And I think, now I need an app to be part of my fancy project. But I don't know what to call it. So I'll call it something really stupid, like core or common. And that's what they do. This layout says, let's take that cool namespace and we're going to use it for this core app instead. So settingspy is just settings. And URLs is just URLs. They don't exist inside this namespace. And we reserve the project name for this project app. And because this project app is our core app, it potentially has templates which override other templates. It needs to be first in the installed apps. So we make that change. The baster, we've moved settings outside that inner directory. So we changed the baster settings. We changed the root URL configuration and the whiskey application configuration to remove the namespace. So now I have this project app. When I want to define project-level templates, I put them in the project app. When I want to define project-level static files, I put them in the project app. This is another layout. It's called a micro project. It's a single file Django project. This isn't that new. I've seen people as early as I think 2011 that have demonstrated this idea of a single file Django project. Julie and I blogged about it. We write about it in the book. This is a working Django project. Please don't do this. It's interesting to know that it can be done. But please don't do this. There's better ways to make this so that you don't run into a circular import nightmare, which is why these constructs of moving things into separate files already exists. So if you want to run this hella world with all your views as lambdas, you can do this. Please don't do this. If you want to see a better example, read the book. And this is something that's somewhere in between. It's called a turnkey app layout. It's similar to the project app, but I envision this more for reusable apps. Imagine reusable apps that you could actually deploy because you can't deploy an app. And there's a lot of apps, a lot of reusable apps in the Django world that sort of straddle this line already. E-commerce apps, CMS apps, blog apps that you may want to use as a part of a larger project or maybe that's your entire project. Maybe all my site is is a blog and I just want to install a blog and run it. So I write a reusable app. So it has an app with the models and views. It has a setup py so I can pip install it. And it has a wsgi file so that I can deploy it. My wsgi file looks something like this. It kind of takes inspiration from the micro project. It configures the settings if the settings aren't configured. So people can override the entirety of the the configurations or you can give them same defaults. You can also envision things like pulling settings from the a less environment from a configuration file and it becomes deployable. You pip install it. You tell gunicorn to run it. So the real summary here is projects don't exist. You've all been living a lie. Stop worrying about where files should go and just build cool stuff. These are some of the photos I used and thank you. There's time for questions and you have questions. I'd love to hear them and check out lightweight Django. It's in pre-release by Riley. I have some discount cards if you are interested. Thank you.