I have to pull out my flip flops. Last week I read the slides from the orange haired guy (Alex I believe), "Why Django sucks...", and found it interesting. Today I watched it, and maybe I'm just an audio learning sort of guy, but I am truly sold on the idea of focusing on the core APIs to make developing your own plugins easier, and leaving those plugins out of the core or contrib. That's not to say I would like to have thumbnailing built in still, but in the interest of the greater good I now officially "flip flop". I think Alex made some really compelling arguments. If Django as a core web framework worked way better (It's excellent now, but it could be better performing, upgraded quicker, easier to plug things into (more modularity at some levels), and acted only as an ORM / Template / Sessions framework at some future point, perhaps the satelite projects (such as "easy- thumbnails") would be more plentiful and better. More competition equals better quality (or price fixing, but I digress). Today I visited http://djangopackages.com/ (linked above) for the first time. This sort of things is excellent and promotes progress, without halting evolution just to make the whiners (ie, me 1 hour ago) happy with cheap built-ins. Gosh, I really pulled a John Kerry on this one; sorry.
My vote on my own idea is -2 (one to reverse the initial proposal) On Sep 16, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com> wrote: > FWIW +1 for moving away from contrib for me. > > Let the core focus on core functionality and people who both more > qualified and passionate about "contrib" pieces to manage that > functionality without being burdened by the core release cycle > patterns. > > D > > On Fri, Sep 17, 2010 at 5:53 AM, burc...@gmail.com <burc...@gmail.com> wrote: > > Hi everyone, > > > I think thumbnailing functionality is much closer to django core > > rather than to django.contrib, and that is the most important reason > > for inclusion. > > > Django provides ImageField out of the box, but why it doesn't provide > > ThumbnailImageField out of the box? > > Django provides {% lorem %} tag, but why it doesn't provide {% > > thumbnail %} tag? > > > Thumbnails are very common pattern. > > > Maybe this application (easy_thumbnails) is not the best choice, but > > the general idea of having good and popular reusable thumbnail > > solution distributed with django is very attractive to me. > > > On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly <jus...@justinlilly.com> > > wrote: > >> One of the criteria for django.contrib is that the item for inclusion > >> is a "de facto standard implementation of common patterns"[0]. From > >> your own admittance there are conflicting views about how this should > >> be handled. Perhaps if someone abstracts this out a bit and has > >> something like image processing backends, it may make a bit more sense > >> for inclusion, but as it stands, I'm -1. > > >> -justin > > >> [0]:http://jacobian.org/writing/what-is-django-contrib/ > > >> On Thu, Sep 16, 2010 at 1:26 PM, ptone <pres...@ptone.com> wrote: > > >>> On Sep 16, 9:43 am, Patrick Altman <palt...@gmail.com> wrote: > >>>> Another "community voice" contribution on this thread... > > >>>> I am of the opposite opinion. I think it would be better for Django as > >>>> a whole if django.contrib approached zero. In fact, I would have no > >>>> problem with seeing it go away completely and promote auth and sessions > >>>> to core but done in a way that is pluggable. The reasoning behind this > >>>> opinion is that it leaves the surface area in the project smaller to > >>>> maintain and it's really not that hard to add a sorl-thumbnail external > >>>> app to a Django project. Furthermore, it provides more freedom for > >>>> these apps to mature and develop at their own pace. > > >>>> I realize I could very well be in a minority opinion here, but thought > >>>> I'd throw it into the mix nonetheless. > > >>> Another vote for evolving away from contrib. > > >>> My hope is that one dayhttp://djangopackages.com/will become > >>> packages.djangoproject.com > > >>> (and along with that a management command startapp-dist which starts a > >>> distributable skeleton) > > >>> -Preston > > >>>> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote: > > >>>> > I have absolutely no pull in decision making, but maybe my message > >>>> > will count towards a "community voice". > > >>>> > I think that including an image thumbnail package that integrates into > >>>> > the database as easily as sorl.thumbnail and easy_thumbnail are is a > >>>> > great idea. From what I can tell, sorl.thumbnail was the de facto > >>>> > standard for getting thumbnails in to Django, and I think it has just > >>>> > as much of a place in Django contrib as some of the other contrib apps > >>>> > do. I don't think it belongs in the core, but contrib seems like an > >>>> > excellent place for it to go along with the other batteries in the > >>>> > pack. > > >>>> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma <baxterstock...@gmail.com> > >>>> > wrote: > >>>> > I have no data to support the following assertion, but it's not too > >>>> > unreasonable: More people probably need thumbnail images than they > >>>> > need comments. Comments are most used on blogs, whereas thumbnails can > >>>> > be used on blogs, e-commerce, photo hosting, social networking, > >>>> > project management, et al. It's not to say that we don't need > >>>> > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > >>>> > On Sep 15, 11:32 pm, "David P. Novakovic" <davidnovako...@gmail.com> > >>>> > wrote: > >>>> > > Actually, that really did sound negative. Sorry :) > > >>>> > > Is there a trac ticket open to address this issue? Generally it'd be > >>>> > > better to get discussion happening over a ticket and if there are > >>>> > > serious issues that need to be addressed then they can be discussed > >>>> > > here. > > >>>> > > I know it'd be nice to get things like easy-thumbnails accepted into > >>>> > > django.contrib , but the truth is that this probably falls outside of > >>>> > > things that that should be in contrib. Contrib isn't really an easier > >>>> > > way to get stuff into django, it still has to satisfy a bunch of > >>>> > > conditions like the rest of the code in the core. > > >>>> > > The real question is not "can it be included?" but why is it a > >>>> > > problem > >>>> > > that this is a third party lib at the moment? Is there a strong case > >>>> > > that it be better if it was part of django core or does it do its job > >>>> > > just fine the way it is now? > > >>>> > > David > > >>>> > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > >>>> > > <davidnovako...@gmail.com> wrote: > >>>> > > > I don't want to sound negative, but answering your own question > >>>> > > > before > >>>> > > > anyone else can doesn't change the answer ;) > > >>>> > > > D > > >>>> > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > >>>> > > > <baxterstock...@gmail.com> wrote: > >>>> > > >> Is there any plans to > >>>> > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > >>>> > > >> into django.contrib? I have seen so many apps/libraries come into > >>>> > > >> and > >>>> > > >> go out of existence > >>>> > > >> (http://code.djangoproject.com/wiki/ThumbNailsfor > >>>> > > >> instance mentions sorl-thumbnails which is no longer being > >>>> > > >> developed). > >>>> > > >> I just turned the key with easy-thumbnails and voila. It's like > >>>> > > >> magic, > >>>> > > >> but not. It's easy enough to see what's going on behind the > >>>> > > >> scenes. > > >>>> > > >> This is something that, with the help of the core and other > >>>> > > >> contributors, could be really great. It works for me as it it is, > >>>> > > >> but > >>>> > > >> it may not work for a more "enterprise" application that uses S3, > >>>> > > >> etc. > >>>> > > >> It might not be highly efficient (I wouldn't know). It might have > >>>> > > >> bugs > >>>> > > >> that I just haven't noticed yet. I'm mentioning all of this > >>>> > > >> because I > >>>> > > >> know somebody will say, "Why move it into Django if it's doing > >>>> > > >> just > >>>> > > >> fine as a separate project?". After experiencing the bliss I > >>>> > > >> thought > >>>> > > >> I'd drop a line here about it, and see what you guys thought. > > >>>> > > >> -- > >>>> > > >> You received this message because you are subscribed to the > >>>> > > >> Google Groups "Django developers" group. > >>>> > > >> To post to this group, send email to > >>>> > > >> django-develop...@googlegroups.com. > >>>> > > >> To unsubscribe from this group, send email to > >>>> > > >> django-developers+unsubscr...@googlegroups.com. > >>>> > > >> For more options, visit this group > >>>> > > >> athttp://groups.google.com/group/django-developers?hl=en. > > >>>> > -- > >>>> > You received this message because you are subscribed to the Google > >>>> > Groups "Django developers" group. > >>>> > To post to this group, send email to > >>>> > django-develop...@googlegroups.com. > >>>> > To unsubscribe from this group, send email to > >>>> > django-developers+unsubscr...@googlegroups.com. > >>>> > For more options, visit this group > >>>> > athttp://groups.google.com/group/django-developers?hl=en. > > >>>> > -- > >>>> > Brian O'Connor > > >>>> > -- > >>>> > You received this message because you are subscribed to the Google > >>>> > Groups "Django developers" group. > >>>> > To post to this group, send email to > >>>> > django-develop...@googlegroups.com. > >>>> > To unsubscribe from this group, send email to > >>>> > django-developers+unsubscr...@googlegroups.com. > >>>> > For more options, visit this group > >>>> > athttp://groups.google.com/group/django-developers?hl=en. > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "Django developers" group. > >>> To post to this group, send email to django-develop...@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> django-developers+unsubscr...@googlegroups.com. > >>> For more options, visit this group > >>> athttp://groups.google.com/group/django-developers?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django developers" group. > >> To post to this group, send email to django-develop...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> athttp://groups.google.com/group/django-developers?hl=en. > > > -- > > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > > MSN: bu...@live.com > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.