Portable Django
djngo.com
djngo.com
https://www.youtube.com/watch?v=ANArGmr74u4
And, err.. well, the very namesake of the project to begin with.
They're just saying they don't want to have to think about slavery when choosing software which seems not unreasonable to me.
“Remember those times your ancestors were enslaved?
Which relates to a history of segregation and oppression so recent that your parents were alive when it was overturned? You must remember it since it’s still championed by secessionists and is the cause of ever present police brutality.
Remember that? Well wow, do I have a funny joke for you!”
Long story short, there are other jokes that could be made.
As a competent HN reader you certainly are basing your view on some facts?
Don’t get name wrong, I don’t think the OP meant something malicious and I don’t want to word police in general. It’s just that this joke comes up all the time when Django is mentioned in a crowd. It may have been funny once but now it’s just kind of banal.
Is it efficient or web scale? Probably not, but I will definitely consider this rather than say Gooey.
I'm running
curl -O https://djngo.com/djngo.com
shasum -a 256 djngo.com
6133a4f5c76af6ca6a2b2eba115783a78fc1721cd384539076884f640b801a26 djngo.com
I tried running it anyway (smart I know) and it failed with
zsh: exec format error: ./djngo.com x@m1n1n0 ~> chmod +x djngo.com
x@m1n1n0 ~> sha256sum djngo.com
6205984f572575c407ce65502361b554af17584f076076bec7440613459d 1dff djngo.com
x@m1n1n0 ~> ./djngo.com
extracting blink-darwin-arm64 to /var/folders /fn/4cdpvwcx1wnc53rzl2m0pn_m0000gn/T//.ape-blink-0.9.2
Python 3.6.14+ (Actually Portable Python) [GCC 9.2.0] on cosmo
Type "help", "copyright", "credits" or "license" for more information.
>>: shasum -a 256 djngo.comDoes the sha256sum command return a different value? It doesn't seem to be installed on my Mac by default.
If you need any help getting started, please join us on the Redbean Discord: https://discord.gg/eHtVmUEB
zsh: exec format error: ./djngo.com
Do the Cosmopolitan/Blink/αpε hacks only work w/ bash on arm macos?
edit: looks like it's a known issue https://github.com/jpe90/hello-cosmo#note-running-with-zsh
I know about Electron and Tauri and all that but this seems like an intriguing possibility to work on.
- Apple x86_64 and ARM64
- Linux running x86_64 or ARM64 (Raspberry Pi)
- Windows running x86_64 and possibly ARM64 too
- FreeBSD, NetBSD, and OpenBSD running x86_64
It does not require that Python be installed beforehand. It's a native Python executable. It does not require Rosetta or Qemu be installed either, in order to run ARM64 platforms. It does not require Cygwin or MSYS2 runtimes in order to run on WIN32. It only depends on KERNEL32. It has an embedded JIT VM called Blink (https://github.com/jart/blink) which it pulls out on non-x86 platforms to emulate itself. All its dependencies are bundled inside using a zip polyglot, including the Python standard library:
unzip -vl djngo.com
...
5588 Defl:N 1707 70% 02-23-2023 16:06 26fb04f6 .python/django/shortcuts.py
0 Stored 0 0% 02-23-2023 16:05 00000000 .python/ctypes/
34 Stored 34 0% 02-23-2023 16:05 1b5bb9b2 .python/ctypes/__init__.py
-------- ------- --- -------
35075517 11728493 67% 7171 files
This means that if you're a Django app developer, you can now easily share your apps with others wanting to run it locally. It's almost as easy for anyone on any platform to use, as if you productionized it onto a website. Rather than a hyperlink away, it's a single file download and CLI invocation away. You won't need to explain things like, "here's how you install Python on Windows" or "here's how you install Docker and setup a Linux distro, in order to run my app." Your users will be in full control of the app, granting maximum privacy and control over data, and zero operations toil for you!
Making Django work on Py3.11 involved the following steps (see commit history for https://github.com/ahgamut/cpython/tree/cosmo_djngo):
- add django + deps to the Lib/ folder - add sqlite3 and zlib to the build system - run quick tests and small examples to check the build works
I expect there's a bunch of packages like django which can be ported similarly. If anyone's interested, this is a fun area to explore.
But if you want Django 4 and Python 3.11, here is some info copied from the website:
3. Newer Python and newer Django? It is possible to have a djngo.com with Django 4 and Python 3.11. Solved by aghgamut who was the first to port Python to Cosmopolitan. Please note that this Python and the one that djngo.com use are different, the later has been heavily optimized by jart to run well on cosmo, the former is as close as upstream as you can get. Choose your destiny.
Python 3.11.0rc1, Django 4.1.7. I think ingenieroariel also has a binary available on the website.
It's a proof-of-concept (because I wrote it just a few hours back), but it shows that we could have the latest version of Python+Django packaged in a single-file executable. Someone could definitely improve upon the build process (like it was done for Python3.6) and add more packages if they wanted.
It's mentioned right there
I only used that version because it is the official one supported by cosmopolitan, but it is also possible to use newer versions with the same approach, for example Python 3.11 and Django 4: https://github.com/ahgamut/cpython/tree/cosmo-djngo (Website has been updated to point at that one).
I've now been writing django at work for five years and still have yet to come across a query builder/orm which is as powerful yet simple in addition to being a breeze to on-board new engineers with.
When there are queries that require the use of non-django builtins, it's also relatively easy to use django raw sql or just straight up use the psycopg2 sql.SQL dynamic string composition helpers.
With the complexity of some our chained django QueryMethods, the company would have quite literally been impossible to build without django's query builder, at the very least.
At scale, poorly understood ORM-generated queries can be a real pain, especially if your team's SQL skills have atrophied due to over-reliance on the ORM.
As an exercise, I'd possibly recommend reviewing your top 1-3 worst performing queries, tracking them back to the ORM, and evaluating how to improve them.
People often overestimate how often the average website needs to worry about scale.
And how easy it is to fix the times you come close.
Edited to say: as for the average website, I do completely agree. For the unique website that will scale as well, I likely would still 95/100 recommend the ORM, but my experience has taught me that there be some pain on the road.
Yes, of course.
Yes, people are still using Django.
As I've grown in my career, frameworks, libraries, and architectural patterns just become tools. I don't quite understand folks who identify as a "React developer", or a "Django developer". When evaluating any framework, you must learn to eschew the latest hotness long enough to evaluate what your requirements are, and maybe most importantly, what your constraints are.
For a surprising amount of projects today, I would still recommend Django above anything else.
- Admin panel? Django has me
- Web forms? Django has me
- Testing? Django, again has an out of the box solution
- Latest in security practices[0]? Again, covered for free
Flask, boy oh boy. I want an ORM? Guess I have to search around, Flask-SQLAlchemy has a lot of hits, I guess? Emails? Well, the Flask Mega-Tutorial uses Flask-Mail[1], guess I will use that. Oh look, it has not been updated since 2014[2]. Hope there is not a security flaw in there[3].
Django follows best practices, and has a huge community ensuring that there is adequate coverage and features required for modern development.
[0]: https://docs.djangoproject.com/en/4.2/releases/4.2/ note on the BREACH attack
[1]: https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...
I am by no means a fan of flask. However it gives you a lot more freedom to structure your application to your taste. Django is basically a php 5.4 framework with a python syntax.
In this day and age fastAPI is a solid choice, so is falcon and probably half a dozen others.
import os
from django.conf import settings
from django.core import management
from django.conf.urls import url
from django.http import HttpResponse
# Django 2.2 Release Notes
# https://docs.djangoproject.com/en/4.1/releases/2.2/
# Documentation
# https://docs.djangoproject.com/en/2.2/
__version__ = 0.1
DEBUG = True
ROOT_URLCONF = 'project'
DATABASES = {'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'project.db' }}
SECRET_KEY = os.getenv('SECRET_KEY', 'Please set a SECRET_KEY as an env var.')
if not settings.configured:
settings.configure(**locals())
def index(request):
return HttpResponse('Hello Django!')
urlpatterns = [
url(r'^$', index),
]
if __name__ == '__main__': # pragma: no cover
management.execute_from_command_line()With that being said, I hadn't thought much about "before Flask". I very well might feel differently if I had been coding then.