Hacker News Reader

Comment by scarygliders | Hacker News Reader

Right as I was just about to start a new Django project...

The thought going through my mind right now is "I wonder if there is some way of creating a Django project and make it resilient to future Django updates and releases with minimum fuss?"

I've had to deal with ongoing and inherited legacy projects which run on Python 2.7, use the long-deprecated Pylons, for which there is no easy upgrade path other than a total re-write in less deprecated technologies. No practical way to convert that Pylons project to Pyramid, for example.

I guess the answer to my thought above is to "Not do/use anything /too exciting/ when creating your Django project" - i.e. only use the most basic and generic Django features, but even then what's to say those won't get deprecated in favour of some new exciting replacement?

I guess that's one of the dilemmas developers have day to day?

View on HN

I feel your pain. If maintainability is your concern, I would advice to skip this release as it won't have long term support. The current LTS release is still 2.2 and will only be replaced with 3.2 sometime in 2021.

You probably already know, but the long term release timeline is shown at https://www.djangoproject.com/download/

Sticking with LTS releases really helps. You'll still have nearly a year to migrate from one LTS release to the next.

In my experience it also helps to avoid small (e.g. a single developer) and young Django apps and stick to the big ones. The amount and quality of the documentation can also be an indicator of longterm viability of the project.

I've done a few more significant migrations (including Python 2 to 3), and about the only bad things are apps whose development stopped and those with developers implementing hacks using Djangos internal API. Everything else is usually done in less than a day for the whole Django project. I only did small projects with 5-10k loc, though.

I work as a contractor and have codebases in python, f#, delphi, swift, obj-c and now rust.

> "I wonder if there is some way of creating a ???? project and make it resilient to future??? updates and releases with minimum fuss?"

- Use control version (mercurial, git, ...) in everything, including utils and side projects.

- Record all dependencies somewhere in the project.

- Automate the builds, so you also have how reconstruct the project

- Use VM or containers or virtual envs or similar

- Rely in a small "core" of solid dependencies (in my case: PostgreSQL, sqlite3, nginx, ubuntu LTS) that could cross across projects and versions.

- Reduce dependencies (but each day is HARDER and HARDER) or better, NOT USE VERY FANCY STUFF (rely on PAAS or kool-aid kind of tech.) For example, If I rely in a http client library it can be dead years after I need to upgrade. That sucks, but, a "http client library" is so "normal" to have that I can rely in found a alternative easily. However, if I base everything on top of Firebase or other cloud stuff, if it die... good luck with that!

Very interesting. I myself was dealing with a Java project I need to maintain for legacy reasons on MySql 5.1. I Just spoon up a Django project aside, and used Peewee[0] to access without changes the DB. Works like a charm and easily integrated in Django midleware.

[0]: https://github.com/coleifer/peewee/issues/1995

>NOT USE VERY FANCY STUFF

They said "with minimum fuss". Write every non-trivial functionality yourself from scratch is the opposite of minimum fuss.

When you use something fancy, and the devs stop supporting it, worst case is you have to write it from scratch yourself at that point, or hope that an alternative exists.

Your suggestion is acting like they don't exist in the first place and write stuff yourself like fancy stuff disappeared - it is a huge hassle and investment all the same.

I mean VERY fancy stuff. Things nearly "experimental" or that rely in a huge black box. Like "not chance in hell I could replicate it" instead of "very hard, but doable".

I know everything have "but..." somewhere (for example: We rely in operating system and the browser, 2 things too hard to recreate) but the idea is always about minimization.

Sometimes you NEED to rely in VERY fancy stuff... but then you are walking on luck...

> i.e. only use the most basic and generic Django features

I don't think you need to do this with Django. Features are generally very mature, stable, and are not deprecated frequently. When they are, they are deprecated years in advance with long term support still provided.

In all honesty, I've seen very few projects run feature lifecycles as well as Django. I'd use everything you need to in it without concern about this.

Seconded, I haven't really had many problems upgrading Django projects, and I've upgraded a lot of them.

Yep. I work on a codebase started with 1.4 and we're on 2.2 now, and almost all of that was straightforward. The biggest difficulty was migrating from South to Django migrations, and that was only because we did it between real releases on Django's master branch (we don't do that anymore!).

I just finished rewrite of big (400+K LOC) 10 year old pylons codebase to pyramid. We were able to share our models, services and 100% template code, and about 80% of view code was untouched.

What you want to do is follow this recipe:

https://docs.pylonsproject.org/projects/pyramid-cookbook/en/...

You put a 404 handler in pyramid to delegate not found views to pylons, and move views one by one.

In a pyramid tween you can push pyramid session, settings, request,response to pylons app globals. This approach works really well - you don't have to do total rewrite. You have same request/response objects, same sqlalchemy ORM, so you can certainly take advantage of that during migration. I don't think anyone at our company regreted the path we took and it was a massive codebase that was making money - no one can afford rewriting that from scratch in $WHATEVERISCOOL today solution.

It certainly is possible - if you need any hints contact me.

Awesome reply :)

This project has reached its end of life, as far as the owners of the site are concerned. I've just completed a 4 month revamp on it, basically giving it a facelift by moving it from hand-crafted CSS, javascript and crufty old templates, to Bootstrap 4 and a more modern look, with some new features; project "Lipstick on a pig".

The company in question has plans for new areas of business for which this site won't be able to handle. It's simply not worth spending the time, bother (and money) trying to hammer that round peg into new square holes, and hence not worth rewriting to Pyramid. The revamp mentioned above will tide them over until something more suitable (and bespoke) is created, which is where Django comes in.

Well, there were a few things in the 2.x series (e.g. naming of default auth views) which ended up breaking existing code and needed updates.

But in all honesty: django is the project I would worry about the least here. Even when stuff is deprecated, an improved alternative tends to exist and is pretty well documented. The level of care that goes into each release is very high; the number of brown bag bugs that get out very low. If you want a quiet life, django is a very good fit.

> "I wonder if there is some way of creating a Django project and make it resilient to future Django updates and releases with minimum fuss?

Have lots of automated tests. The more surface area you cover, the easier it'll be to upgrade.

> [...] use the most basic and generic Django features, but even then what's to say those won't get deprecated in favour of some new exciting replacement?

In my experience, Django maintainers are slow to rush to new exciting replacements, and even slower to deprecate and remove things. From a compatibility perspective and ongoing maintenance, it's a great approach!

>Right as I was just about to start a new Django project...

It's rarely a good idea to use the latest version of Django simply because most projects will be reliant upon 3rd party libraries which will often be slow to catch up to supporting the latest version.

The difference between 2.2 and 3.0 is quite small, as you can see in the release notes. Most projects won't need changes.

Some languages are more prone to prioritize of your previous investment. The most popular examples are Java, C# and Go. Different tools for different needs.

Perhaps it's time to think about ditching the "batteries included" monolithic frameworks like Django (Rails etc.) and start your serverless/microservices/docker/k8s/etc journey.

The beauty of this type of architecture is that you don't need to worry about upgrading your entire stack just because your underlying framework bumped a version number. You can create a service w/ Pylons here, a service w/ Whatever there, and lock them down without needing to refactor them all just because you want to add another feature.

… and then you have to track versions in many places and test all of the various combinations yourself rather than having a third-party do it. Microservices have their advantages but they are not a magic wand for dependency management unless you’re using very little of a framework.

Edit to add: I would class an advantage of microservices if it made it easier for you to have automated tests or deployment/rollbacks, since that’s much more effective for this problem in my experience. I’ve seen people do that with monoliths and fail to do that with microservices so again, no magic wands.

No.

You push all your complexity to your infra, where you end up having an order of magnitude less visibility, way more problems debugging trivial issues, and making your life more difficult for dumb, simple problems that have been solved two decades ago.

Monolithic frameworks are amazing. They have well-designed APIs by people who don't want to waste time upgrading to the latest framework of whatever, and splitting them into actual services is equally complicated provided you've architected them well. And you haven't, it's as much of a PITA as any "serverless" thingy of the day.

Reply on news.ycombinator.com