Re: collectstatic command should output minified files

There is CSS / Javascript merge and compress package for Python: https://github.com/miracle2k/webassets which supports Django, Flask, Pyramid. See also: https://www.slideshare.net/__amol__/pyconit7-dukpy-webassets-free-yourself-from-nodejs-chains https://pypi.org/project/dukpy/ https://gist.github

Re: collectstatic command should output minified files

django-compressor is also popular: https://pypi.org/project/django-compressor/ IMO we should not include anything in Django since JavaScript is a separate language, and they have much better tools for minification and bundling, and these tools can move faster than and orthogonally to Django. And t

Re: collectstatic command should output minified files

There is one trouble: Webpack assumes it's own subtree of assets to process, while Django loads assets from packages (Django apps) directories. I still haven't seen a successful setup of webpack which would respect loading assets from Django packages directories. Another trouble, not everyone wants

Re: collectstatic command should output minified files

I didn't mean we should include things in Django. Even a workflow that integrates with Django using manage.py commands will be super useful. Right now, I use Parcel + Tailwind (csspostprocessor mostly) + done JavaScript. It's supposed to be simple. Even for this, I need to run to terminals (one

Re: collectstatic command should output minified files

Correct. Also having to use third party packages (and even other languages!) for something so common and so useful feels incorrect somehow. Additionally, I also propose that the HTMl files served by wsgi.py are minified. This will be significantly more difficult to achieve since HTML pages ar

Re: collectstatic command should output minified files

*-1* Correct. Also having to use third party packages (and even other > languages!) for something so common and so useful feels incorrect somehow. > > Additionally, I also propose that the HTMl files served by wsgi.py are > minified. This will be significantly more difficult to achieve since H

Re: collectstatic command should output minified files

Additionally, I also propose that the HTMl files served by wsgi.py are > minified. > This can already be done with e.g. https://htmlmin.readthedocs.io/en/latest/reference.html#wsgi-middlware . But normally HTML minification isn't particularly worth it since gzip/brotli can compress it well alread

Re: collectstatic command should output minified files

For those who want more information on getting Django to serve your frontend assets, Aymeric wrote some good react-focussed blog posts: https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/ On Tue, 22 Dec 2020 at 12:43, Adam Johnson wrote: > > > Additionally,

Proposal: Permit __file__-less migrations packages

Django developers, The migration loader currently loads migrations only from apps whose migrations package has a __file__ attribute. The reason for this check, given both in the source code comments

Re: Proposal: Permit __file__-less migrations packages

I've hit several problems with PEP-420 namespace packages in the last few months, which inspired me to create flake8-no-pep420: https://pypi.org/project/flake8-no-pep420/ . In summary, I found pep-420 namespace packages are not checked by Django's test runner, coverage.py, or mypy (with its bonus f

Re: Proposal: Permit __file__-less migrations packages

As I said in my original post, I *do not propose to change the behavior of Django with respect to namespace packages*. My proposal only makes the check for them more specific so that we permit *regular* packages run from Python environments that do not set __file__. On Tuesday, December 22, 202

Re: Proposal: Permit __file__-less migrations packages

Hi, I can only repeat my arguments from the ticket. I don't see a strong reason to add an extra dependency for this. Django 4.0 will drop support for Python 3.6 and Python 3.7, so we can reconsider this ticket when developing Django 4

Re: Proposal: Permit __file__-less migrations packages

I now see that my original post was too vague. I will more thoroughly explain myself below, including the actual patch (because it's that short!). *My proposal will not change Django's behavior at all for anyone not using "freezers" *such as PyOxidizer, cx_Freeze, Nuitka, PyInstaller, and the l

Re: Proposal: Permit __file__-less migrations packages

Hi, Thanks for extra details. It's not about the number of LOC. I have the impression that more changes are needed to support "freezers" , see the previous discussion about PyOxidizer . Are we sure this is the only

Re: Proposal: Permit __file__-less migrations packages

Mariusz, Thanks for your response! *> I have the impression that more changes are needed to support "freezers" Are we sure this is the only change that is needed?* Django will indeed require changes beyond today's proposal for full freezer support. I am pursuing an incremental approach her

Integrating migrations with the check framework

Hey, A fairly common problem with large and/or highly trafficked web applications is migration safety: you want your migrations to be non-locking and instantaneous. The specifics are very database dependent but in Postgres simply altering the nullability of a column can incur serious downtime depen