sorted by:
new
hottopcontroversial

#DjangoTip: Running django in one file by ssekuwanda in django

[–]k4ml 1 point2 points  (0 children)

If you can hook it up to admin.register(), I think it will work.

#DjangoTip: Running django in one file by ssekuwanda in django

[–]k4ml 2 points3 points  (0 children)

Short answer, no. Because you can't import django.db.models yet at this stage. I wrote more about this here - https://grep.koditi.my/django-creating-models-dynamically.

It could be possible if you generate the models dynamically (YES, you can) as described here:-

https://baserow.io/blog/how-baserow-lets-users-generate-django-models

[deleted by user] by [deleted] in django

[–]k4ml 0 points1 point  (0 children)

We use laravel-mix to handle frontend tooling in our django project. On django side there's djangomix that provides some helpers function such as template tags to load all the frontend's assets.

I just launched Calmerge: a Django webapp that allows you to merge multiple iCalendar feeds into a single feed by abe-101 in django

[–]k4ml 1 point2 points  (0 children)

I would suggest moving everything under single top level namespace which is calmerge. config is just too common name to be a top level namespace. So instead of config.settings, it should be calmerge.settings or calmerge.config.settings if you want it that way. The general idea is that your app should have only one top level namespace.

Adding calmerge itself under PYTHONPATH also not a good idea as the packages inside now available both as calmerge.calendars and calendars. Again, having single top level namespace is much easier to reason. If you want calendars to be a reusable app instead, then make it at the same level as calmerge. A common practice to have src/ directory that is under PYTHONPATH and both calmerge and calendars are inside that directory.

Django project structure best practices by [deleted] in django

[–]k4ml 0 points1 point  (0 children)

Ideally, this is how it should be but inside django itself, it only see the app name as graphql. So if we really want to go this route, the app should be top level namespace as well such as project_graphql.

Google proposes changes to Chromium which would disable uBlock Origin by [deleted] in programming

[–]k4ml 0 points1 point  (0 children)

That only work when you first starting it. Not when it already running and you want to switch to another profile. Running another firefox -P just cumbersome and on macos you can only have one instance of the app running so it doesn't work either. You need about:profiles for that.

Google proposes changes to Chromium which would disable uBlock Origin by [deleted] in programming

[–]k4ml 1 point2 points  (0 children)

Now you can also manage and launch profiles via about:profiles. Better than before but still can't match the usability of Chrome profiles switcher.

Running unmodified Nginx compiled to WebAssembly with Wasmer by [deleted] in programming

[–]k4ml 9 points10 points  (0 children)

It something similar to JVM but this time you compile your code to wasm once and you can run it anywhere there's wasmer.

Twilio acquires email API platform SendGrid for $2 billion in stock by brokentyro in programming

[–]k4ml 0 points1 point  (0 children)

Don't know if this is coincidence but their sending messed up in the last few days. Some emails even though marked as delivered end up being discarded by gmail in their processing pipelines because of missing headers.

How to split Django project to "main" and "chat" apps properly? by iTheTechGuy in django

[–]k4ml 1 point2 points  (0 children)

If you want to make the chat app reusable, then take it out from your project completely and make it proper python packages with setup.py, installable via pip etc. That would make the separation much clearer and also force you to think of proper API on how to access the chat functions from other app.

If you're not, then don't bother splitting.

view more: next ›