6 ms·

I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps

I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse. This seems to me to be somewhat unpythonic, unnecessary complexity introduced right from the start - why not make the reuse optional?. The file system layout becomes confusing as a result. More generally, I would expect that the most minimal Django site would be a single file, that would seem most Pythonic, but it isn't designed like that. Django doesn't "feel" like most Python projects do. I've always assumed this must be because I'm a total noob/idiot when it comes to real-world development, and that projects like Django must be doing things right and I just don't get it (although it remains entirely possible that this is the case). It's heartening, however, to see I'm at least not _entirely_ wrong for having a gut unease about this, and it makes me wonder how on earth I can judge whether it's me or a given framework/language in the general case. Do I have reverse Dunning–Kruger? Or did I just guess right in this case? I have no idea.

mi100hael 9y ago
Part of it is that Django has been around for quite a while now. It's maybe _the_ most succesful Python framework out there, so there are some paradigms that aren't common anymore but are hold-overs from years past. In particular, it pre-dates the current "microservice" trend and assumes a fairly monolithic environment. And I think "apps" _do_ make sense in certain contexts. Consider this situation: - I start a "polls" app like the Django docs example. - I get a lot of users and they like my functionality, so I want to engage the community. - I decide to start publishing blog posts, but I'm too lazy to spin up a whole new Wordpress install - I find a "blog" app and drop that into my project with the '/blog' URL prefix. Now I can start writing blog posts right away and anyone can go to my site '/blog' and see it. There are no cross-app database dependencies to worry about. The same would be true for adding a basic "social" app that shows a user-profile page for django Users at '/users/<id>' or something like that.
- randomsearch 9y ago
  The polls app example is given in the introductory Django tutorial...
  - mi100hael 9y ago
    Yes, that's what I said...?
    - randomsearch 9y ago
      Sorry, misread that line. Point being, how many examples do you have where someone writing a Django site is going to reuse their own apps?
      - soperj 9y ago
        I reuse my own apps constantly, whenever I do new sites.
        randomsearch 9y ago
        Excellent - could you give some examples of what you reuse? I'm interested in whether this is a worthwhile abstraction in the general case, or whether for most people (like me and the post) it's an unhelpful complication.
        mi100hael 9y ago
        It's a worthwhile abstraction for any generic feature that isn't specific to the one project you're working on: - User profiles - Content management/publishing - Messaging and chat - Searching your database - Admin - Analytics on your database Segmenting into apps makes the most sense when there are no cross-app dependencies on migrations: additional read-only capabilities on your existing models in another app, or new capability using entirely new, stand-alone models.
  - deleted 9y ago
crdoconnor 9y ago
>I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse. Yes, let's say you install a module that has a specific Django functionality from pypi, it will typically be installed as an app. It confuses newbies sometimes who think that they need to worry about how to divide up their application into different applications. 99% of the time they don't and shouldn't (putting everything in a single app called 'core' in your project is a pretty common pattern). Unfortunately the docs were never very clear on this. >This seems to me to be somewhat unpythonic, unnecessary complexity introduced right from the start - why not make the reuse optional?. The file system layout becomes confusing as a result. More generally, I would expect that the most minimal Django site would be a single file, that would seem most Pythonic, but it isn't designed like that. It can be made to behave like that if you really want: http://olifante.blogs.com/covil/2010/04/minimal-django.html http://olifante.blogs.com/covil/2010/04/minimal-django.html Most people aren't using Django for that though, so it's not widely advertised nor known. >It's heartening, however, to see I'm at least not _entirely_ wrong for having a gut unease about this, It's not like the framework is perfect. There's plenty wrong with it, but it largely managed not to fuck everything up, which is pretty rare.
dangayle 9y ago
Have you checkout out O'Reilly's Lightweight Django book? It basically goes through all of this, starting with a single file Django app.
- randomsearch 9y ago
  No! I read a lot of books, but missed that. Thanks!
- jwarren116 9y ago
  +1 for Lightweight Django. I had the pleasure of working with one of the authors. The book is well laid out and covers some really great topics that aren't always covered well elsewhere in the context of Django (i.e. Websocket services with Django). It's a great companion for Two Scoops of Django.
  - dangayle 9y ago
    In my opinion that book should be the starting point. The official tutorials have you way deep in the weeds with database migrations and stuff before you even have a basic understanding of where you're at and why. Worst "hello world" ever.
Osmose 9y ago
Where app directories are incredibly useful is in Django library development. They're a really convenient way to hook in models, static files, template helpers, etc. to an existing Django site, without forcing users to do a bunch of setup work when integrating your library. It's not a coincidence that most Django libraries have a very similar setup: 1. Install the package 2. Add the package to settings.INSTALLED_APPS (and middleware, etc). 3. Profit! For an instance of a Django site, apps are less useful, and the article's recommendation to be more careful when splitting your site into multiple apps is great advice.
- randomsearch 9y ago
  Yeah, I agree. Makes sense for libraries. So keep that separate for library writers, don't expose me to the complexity of that.
  - andybak 9y ago
    The benchmark I use is "Is it probable that this app might become shared between projects?" Using a Django 'app' for this makes sense. If it's generic enough that I might consider moving it into it's own repo then it's probably not going to be heavily intertwined with the rest of the project.
marcosdumay 9y ago
> why not make the reuse optional? Well, it is optional. You can just not divide you stuff and place everything inside the main app. But notice the article recreates the same layer of reuse inside the main app, and got some extra problems because of it (renaming the tables is probably caused by this). Django may need an extra paragraph at the tutorial, telling how it is ok to place everything on the main app when everything is application specific software, and how you should break generic functionality on other apps. By the way, what would be reverse Dunning-Kruger?
- randomsearch 9y ago
  > Well, it is optional What I mean is, you still have to have a "main" app. Why? I don't want to reuse it. So I don't want an "app". I just want to build my website. Stop making me put things in an unnecessarily complicated directory hierarchy. If it were Java, I wouldn't think twice about it, but it doesn't seem Pythonic. > reverse Dunning-Kruger Good question! Probably... illusory inferiority AKA imposter syndrome. I assumed Django knows best, but maybe it doesn't.
  - bmelton 9y ago
    Sure. One of the Djangoesque opinions is that if you're building a site, you'd like it to be maintainable, and that you'll probably add on to it. If you've been working in the Python ecosystem long enough to know that you're building a site that doesn't have those assumptions, you'll probably pick something different to start out with, like Flask or Bottle.
  - marcosdumay 9y ago
    > you still have to have a "main" app Well, it has to be organized some way. It happens to have the organization that gives you more flexibility, instead of forcing something that only fits very small sites onto you. That means you'll have an extra directory on your tree. Anyway, nobody uses only the main app. The article creates a big amount of problems by trying to only write on it, but I bet that even them use the Django's builtin apps. > AKA imposter syndrome Oh. Dunning-Kruger study detected that one too. It's within the effect: people tend to self evaluate into a small band near (but often under) the top, whatever their real evaluation is.
arctangent 9y ago
A good rule of thumb is that a Django "app" should be (1) standalone and (2) reusable. If you were to write a Django project to automate some complicated internal process at your particular company, it's likely that you'd break up the code into separate Python modules to help give it an easy to understand structure. But it's unlikely that any other company would necessarily benefit from any of those separate modules by themselves. However, let's say you come up with a clever idea about how to log errors in your project. Now, that's the sort of thing that other people might want to use in their own projects. If you were to restructure your code a bit and make it a bit more abstract then you could create a separate "app" that could be dropped into other Django projects.
tlp8800 9y ago
You could write a Django site in a single file if you wanted to. See this for an example: https://www.safaribooksonline.com/library/view/lightweight-django/9781491946275/ch01.html https://www.safaribooksonline.com/library/view/lightweight-d...
jasonthevillain 9y ago
It depends what you're doing. It shines on low level features like authentication and image cropping, where I need ways to do these things, and I can use them across the board. It breaks down when you have a lot of views and urls that are trying to stay close to their related models, but are too interconnected to have any real kind of separation of concerns. I find myself using all of the above. There's nothing wrong with building a small site in a single app, or nesting apps to provide a little more structure for how they're connected or separated.
neves 9y ago
I'm not affiliated with them, but you think seriously about Django, you should take a look at the book https://www.twoscoopspress.com/products/two-scoops-of-django-1-11https://www.twoscoopspress.com/products/two-scoops-of-django-1-11 https://www.twoscoopspress.com/products/two-scoops-of-django... I still have the 1.5 edition, but it helped me a lot. I'm think about upgrading. Do you recommend?

mi100hael 9y ago

Part of it is that Django has been around for quite a while now. It's maybe _the_ most succesful Python framework out there, so there are some paradigms that aren't common anymore but are hold-overs from years past. In particular, it pre-dates the current "microservice" trend and assumes a fairly monolithic environment. And I think "apps" _do_ make sense in certain contexts. Consider this situation: - I start a "polls" app like the Django docs example. - I get a lot of users and they like my functionality, so I want to engage the community. - I decide to start publishing blog posts, but I'm too lazy to spin up a whole new Wordpress install - I find a "blog" app and drop that into my project with the '/blog' URL prefix. Now I can start writing blog posts right away and anyone can go to my site '/blog' and see it. There are no cross-app database dependencies to worry about. The same would be true for adding a basic "social" app that shows a user-profile page for django Users at '/users/<id>' or something like that.

randomsearch 9y ago
The polls app example is given in the introductory Django tutorial...
- mi100hael 9y ago
  Yes, that's what I said...?
  - randomsearch 9y ago
    Sorry, misread that line. Point being, how many examples do you have where someone writing a Django site is going to reuse their own apps?
    - soperj 9y ago
      I reuse my own apps constantly, whenever I do new sites.
      - randomsearch 9y ago
        Excellent - could you give some examples of what you reuse? I'm interested in whether this is a worthwhile abstraction in the general case, or whether for most people (like me and the post) it's an unhelpful complication.
        mi100hael 9y ago
        It's a worthwhile abstraction for any generic feature that isn't specific to the one project you're working on: - User profiles - Content management/publishing - Messaging and chat - Searching your database - Admin - Analytics on your database Segmenting into apps makes the most sense when there are no cross-app dependencies on migrations: additional read-only capabilities on your existing models in another app, or new capability using entirely new, stand-alone models.
- deleted 9y ago

crdoconnor 9y ago

>I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse. Yes, let's say you install a module that has a specific Django functionality from pypi, it will typically be installed as an app. It confuses newbies sometimes who think that they need to worry about how to divide up their application into different applications. 99% of the time they don't and shouldn't (putting everything in a single app called 'core' in your project is a pretty common pattern). Unfortunately the docs were never very clear on this. >This seems to me to be somewhat unpythonic, unnecessary complexity introduced right from the start - why not make the reuse optional?. The file system layout becomes confusing as a result. More generally, I would expect that the most minimal Django site would be a single file, that would seem most Pythonic, but it isn't designed like that. It can be made to behave like that if you really want: http://olifante.blogs.com/covil/2010/04/minimal-django.html http://olifante.blogs.com/covil/2010/04/minimal-django.html Most people aren't using Django for that though, so it's not widely advertised nor known. >It's heartening, however, to see I'm at least not _entirely_ wrong for having a gut unease about this, It's not like the framework is perfect. There's plenty wrong with it, but it largely managed not to fuck everything up, which is pretty rare.

dangayle 9y ago

Have you checkout out O'Reilly's Lightweight Django book? It basically goes through all of this, starting with a single file Django app.

randomsearch 9y ago
No! I read a lot of books, but missed that. Thanks!
jwarren116 9y ago
+1 for Lightweight Django. I had the pleasure of working with one of the authors. The book is well laid out and covers some really great topics that aren't always covered well elsewhere in the context of Django (i.e. Websocket services with Django). It's a great companion for Two Scoops of Django.
- dangayle 9y ago
  In my opinion that book should be the starting point. The official tutorials have you way deep in the weeds with database migrations and stuff before you even have a basic understanding of where you're at and why. Worst "hello world" ever.

Osmose 9y ago

Where app directories are incredibly useful is in Django library development. They're a really convenient way to hook in models, static files, template helpers, etc. to an existing Django site, without forcing users to do a bunch of setup work when integrating your library. It's not a coincidence that most Django libraries have a very similar setup: 1. Install the package 2. Add the package to settings.INSTALLED_APPS (and middleware, etc). 3. Profit! For an instance of a Django site, apps are less useful, and the article's recommendation to be more careful when splitting your site into multiple apps is great advice.

randomsearch 9y ago
Yeah, I agree. Makes sense for libraries. So keep that separate for library writers, don't expose me to the complexity of that.
- andybak 9y ago
  The benchmark I use is "Is it probable that this app might become shared between projects?" Using a Django 'app' for this makes sense. If it's generic enough that I might consider moving it into it's own repo then it's probably not going to be heavily intertwined with the rest of the project.

marcosdumay 9y ago

> why not make the reuse optional? Well, it is optional. You can just not divide you stuff and place everything inside the main app. But notice the article recreates the same layer of reuse inside the main app, and got some extra problems because of it (renaming the tables is probably caused by this). Django may need an extra paragraph at the tutorial, telling how it is ok to place everything on the main app when everything is application specific software, and how you should break generic functionality on other apps. By the way, what would be reverse Dunning-Kruger?

randomsearch 9y ago
> Well, it is optional What I mean is, you still have to have a "main" app. Why? I don't want to reuse it. So I don't want an "app". I just want to build my website. Stop making me put things in an unnecessarily complicated directory hierarchy. If it were Java, I wouldn't think twice about it, but it doesn't seem Pythonic. > reverse Dunning-Kruger Good question! Probably... illusory inferiority AKA imposter syndrome. I assumed Django knows best, but maybe it doesn't.
- bmelton 9y ago
  Sure. One of the Djangoesque opinions is that if you're building a site, you'd like it to be maintainable, and that you'll probably add on to it. If you've been working in the Python ecosystem long enough to know that you're building a site that doesn't have those assumptions, you'll probably pick something different to start out with, like Flask or Bottle.
- marcosdumay 9y ago
  > you still have to have a "main" app Well, it has to be organized some way. It happens to have the organization that gives you more flexibility, instead of forcing something that only fits very small sites onto you. That means you'll have an extra directory on your tree. Anyway, nobody uses only the main app. The article creates a big amount of problems by trying to only write on it, but I bet that even them use the Django's builtin apps. > AKA imposter syndrome Oh. Dunning-Kruger study detected that one too. It's within the effect: people tend to self evaluate into a small band near (but often under) the top, whatever their real evaluation is.

arctangent 9y ago

A good rule of thumb is that a Django "app" should be (1) standalone and (2) reusable. If you were to write a Django project to automate some complicated internal process at your particular company, it's likely that you'd break up the code into separate Python modules to help give it an easy to understand structure. But it's unlikely that any other company would necessarily benefit from any of those separate modules by themselves. However, let's say you come up with a clever idea about how to log errors in your project. Now, that's the sort of thing that other people might want to use in their own projects. If you were to restructure your code a bit and make it a bit more abstract then you could create a separate "app" that could be dropped into other Django projects.

tlp8800 9y ago

You could write a Django site in a single file if you wanted to. See this for an example: https://www.safaribooksonline.com/library/view/lightweight-django/9781491946275/ch01.html https://www.safaribooksonline.com/library/view/lightweight-d...

jasonthevillain 9y ago

It depends what you're doing. It shines on low level features like authentication and image cropping, where I need ways to do these things, and I can use them across the board. It breaks down when you have a lot of views and urls that are trying to stay close to their related models, but are too interconnected to have any real kind of separation of concerns. I find myself using all of the above. There's nothing wrong with building a small site in a single app, or nesting apps to provide a little more structure for how they're connected or separated.

neves 9y ago

I'm not affiliated with them, but you think seriously about Django, you should take a look at the book https://www.twoscoopspress.com/products/two-scoops-of-django-1-11https://www.twoscoopspress.com/products/two-scoops-of-django-1-11 https://www.twoscoopspress.com/products/two-scoops-of-django... I still have the 1.5 edition, but it helped me a lot. I'm think about upgrading. Do you recommend?