James Bennett

Those are interesting pointers; appreciate it! My own experience over the past three years has been similar. I tried using Pipenv, and then Poetry, for internal projects at my company; in both cases the tool seemed overly complicated for the problem, slow, and I had a hard time getting co-workers on board. About a year and a half ago, I saw [Boring Python: dependency management](https://www.b-list.org/weblog/2022/may/13/boring-python-dependencies/), which recommends using the third-party `pip-tools` library alongside the standard library’s `pip` and `venv`, and switched to that for the next project. It’s been working great. The project has involved a small team of scientists (four or five, depending) who use a mix of macOS and Windows. We do analysis and development locally and write production-facing algorithms in Python packages tracked in our repository, and publish releases to Gitlab’s PyPI. For our team, the “get up and running” instructions are “clone, create a venv, and pip install -r requirements.txt” and for the software team that manages the production systems, deploying an update just means pip installing a new version of the package. Every team’s got different constraints, of course, but this has been working very smoothly for us for over a year now, and it’s been easy, no pushback, with everyone understanding what’s going on. Really impressed with the progress of the core Python packaging infrastructure over the past several years.

> All articles are mostly a regurgitation of all the negativity that gets aired here all the time (a lot of it already fixed or debunked) and 0 discussion of utility.

There are multiple sections that talk directly about utility. Here's one of them: [0]

But, sure. I'll bite. Here's the third paragraph of the first part of the essay [1]:

This is *bullshit* about *bullshit machines*, and I mean it. It is neither balanced nor complete: others have covered ecological and intellectual property issues better than I could, and there is no shortage of boosterism online. Instead, I am trying to fill in the negative spaces in the discourse. “AI” is also a fractal territory; there are many places where I flatten complex stories in service of pithy polemic. I am not trying to make nuanced, accurate predictions, but to trace the potential risks and benefits at play.

I'd say that the specific sort of "utility" discussion that you're probably looking for would be classified as "boosterism". [2]

> Now it can scale with power and compute.

Eh. Carefully read through and consider [3].

[0] <https://aphyr.com/posts/411-the-future-of-everything-is-lies-i-guess#models-are-smart>

[1] <https://aphyr.com/posts/411-the-future-of-everything-is-lies-i-guess>

[2] Due to their nearly-universally breathless nature, I know that's how I classify the overwhelming majority of such discussions.

[3] <https://www.b-list.org/weblog/2026/apr/09/llms/>

Ah, the typical "where to put business logic in Django".

M in ActiveRecord MVC web frameworks is deeply misunderstood. M is not "data model" (it would be called DVC if that was the case). M is your domain model. It's the model of your business, model of the real world. It's the core of your application.

Another thing that I never understood, why are functions called services? Is it a subconscious desire to go back to enterprisey kingdom of nouns? (apparently it is [1])

A service is either something that lives on a network (e.g. database, payment gateway, microservice). Or a class that has a state. Your functions are neither of those, they are just functions.

You business logic should live in the "models" namespace. Whether you put it on Model classes, or onto custom Managers, or just dump them into the module is not important, as long as you keep it consistent and keep your apps fairly small and isolated from each other.

Django already gives you enough tools to support big "enterprise" applications. It is far from perfect, but you'll get much further if you embrace the framework instead of fighting it.

If you really are attached to this "services" mindset then Django API Domains [2] is your best option.

[1] https://www.b-list.org/weblog/2020/mar/16/no-service/

[2] https://github.com/phalt/django-api-domains

That’s a hard spot to be in. I can hear your pain on how you want you idea to be launched. Honestly, learning django is no brainer. Django guys have done an amazing job building the framework. On a side note, why is your prototype taking that long? In today’s world, you can build complex apps faster than you can think off.
Here is some links that can be handy for your django learning. All the best!

This is a excellent wiki with lot of tutorial/information/samples about django
http://code.djangoproject.com/wiki/Tutorials
http://www.b-list.org/weblog/2006/nov/16/django-tips-get-mos...
http://www.b-list.org/weblog/2007/sep/04/django-accelerated/
http://www.slideshare.net/simon/advanced-django/
http://djangoplugables.com/
http://www.djangoproject.com/community/
http://djangobook.com
http://showmedo.com/videos/video?name=1100000&fromSeries... http://showmedo.com/videos/series?name=v7kABKL6R http://blog.disqus.net/2007/03/11/a-django-primer/
http://www-128.ibm.com/developerworks/linux/library/l-django...

I think James Bennett's post on magic is interesting: http://www.b-list.org/weblog/2009/jul/23/magic/

In particular, there is a comment[0] that I think is particularly worth reading:

There are two different definitions of magic in play here.

1. The use of advanced language features in a manner that might be confusing to a novice programmer.
2. The use of ANY language feature to automate some process that a programmer would not expect to be automated.

I am of the belief that the second is the proper definition, which is something that is not usually solved by reading sourcecode, as the question is "Why?", rather than "What?" or "How?".

[0]: http://www.b-list.org/weblog/2009/jul/23/magic/#c118751

"Why not create a ‘templates’ directoy and a ‘base.html’ either in project’s directory or in the apps’s directory, because creating the same templates directory and same base.html for every project is not DRY?"

There's nothing wrong with that. Even the djangoproject.com website does it: http://code.djangoproject.com/browser/djangoproject.com/django_website

"Why serving static files in development has to be a additional setup, as no developer wants to setup a server for serving static files, I am aware of ‘django.static.serve’ but still that is an additional setup, why not create a sample media directory and a url for the same in urls.py ?"

Read this: http://www.b-list.org/weblog/2008/jun/23/media/