On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty <[email protected]> wrote:
> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant <[email protected]> wrote: > > Is this up somewhere public? I've been fighting the urge to do this as > > well. Using django-compressor with less on Heroku is a non-starter > > since you can't install node. Having this as a Python module would be > > handy. > > Not yet, alas, but hopefully soon. > > Adrian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > Perhaps this is too far in the future looking. But at a certain point the admin must become a separate project. One of the major goals of newforms-admin ('lo those years ago) was to demote the admin from special status, with hooks inside core left and right, to "just an app". Let's carry that to the logical conclusion: just an app *outside of Django*. That gives the maintainers the freedom to reinvent it, and use tools like less or bootstrap without it needing to be an issue of policy for all of Django. Because when I first read saw this thread my thought was, "Hmm, what unholy mess of requirements am I going to need if I want to just run the test suite. Will I still be able to write new features in forms without needing to learn what the hell less or compass is?". Several years ago, I opposed using jQuery in the admin, on the principle that Django should be completely free of entangling alliances. I made that argument more or less out of habit, just because I felt it was an argument that ought to be made, but really I was pretty happy to get to use jQuery. Now I'm saying, it's pretty clear that admin 2.0 (or 3.0, or 4.0, anyone counting?) is going to be a beast that far outstrips almost anything else in Djanog (besides the ORM ;)) in complexity, with more dependencies, more associated tooling, and more usecases (i.e. it's not just a tool for developers to use, it's also something for end users of *our* users' apps to use). Keeping that in Django itself is going to stunt it's growth, and it's going to suck for new developers to Django who, like many of us (or at least myself), were and still are, Python developers at heart, who can write some HTML, badly. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
