+1 to separate django and admin o other contrib app. -0 to mantain another/alternative admin on contrib
It is understandable at first that was maintained at par for order and security in the project itself. But today, after Django 1.3.1 I think it's time to review the situation of contrib. With teams in each Django contrib application would be a little more flexible. That is my humble opinion :) Regards, On Mon, Feb 13, 2012 at 3:23 PM, Jonathan Paugh <jpa...@gmx.us> wrote: > There's a big rift here between what people want to do with admin and > what people want to do with django itself. To summarize: the admin > should be amazing by itself and chock full of features, while django > should be empowering without getting in the way. > > I've seen a lot of good ideas for admin rejected recently because they > couldn't fit into Django's overall vision. I don't think there is any > way to resolve this rift: it will persist. Django and admin should be > developed separately, likely by separate teams. They could still live in > the same codebase, with an "subofficial" admin fork. Then, the official > django repo could pull in changes according to some suitable policy. > > However, maintaining it as a separate project wouldn't hurt, either: > In address to Anssi's concerns: conteaching pip is as easy as `pip > install django-admin`, and the two projects could be tarball-ed together > somehow. (Could it be that hard to teach setup.py to install another > package from a subdir? Or to tar up them separately?) (And what is > virtualenv? Do I need it to install admin? Let's address that in a > separate tutorial, with a link and a notation.) > > Peace, > Jonathan > > P.S. I'm fairly new here (~1 month), and my perspective is > proportionally skewed. > > On 02/03/2012 02:07 PM, Ryan D Hiebert wrote: > > I think that Django's admin app is a killer feature for two main reasons: > > 1. It is automatically installed, and integrated into the tutorial. > > 2. It is used all over in third-party apps, because they can expect it > to be there. > > > > While I appreciate that there may be differences in core vs admin that > may slow down development of the admin, I'm wary of removing it from the > django install, thinking that it might hurt reason 2, even if it is > integrated in the tuturial, and possibly even installed automatically. > > > > Although as far as the automatic install goes, I'm not sure how that > would work. Would it be a dependency? That doesn't make sense. > > > > On Feb 3, 2012, at 6:21 AM, Max Thayer wrote: > > > >> The point about admin's appeal to new people is important, but > externalizing it and keeping new people from ever seeing it are very > different. Consider: admin isn't even enabled by default. You have to > follow the tutorial on how to enable it. If admin weren't included in > Django proper, we could just change the tutorial to "Apps are awesome; > here's how to download and install one written by someone else." New users > could meet pip sooner, and otherwise understand how to integrate with the > broader python/django community's various creations. > >> > >> Actually, a friend of mine and I have been plotting out externalizing > various parts of contrib, like admin and auth. Are any groups currently > pursuing those goals as well? > >> > >> Best regards, > >> Max > >> > >> On Fri, Feb 3, 2012 at 8:35 AM, Brendan Smith < > bren...@nationalpriorities.org> wrote: > >> I give +1 to the idea of separating out the admin and letting people > fork and modify to their hearts content > >> > >> I also still give my +1 to having it utilize less, but I am also > cautious like others about prescribing bootstrap specifically , especially > the JS since as others have pointed out is somewhat unstable right now and > not very easy to use at times (took me a long time to figure out modals) > >> > >> Sent from my iPhone > >> > >> On Feb 3, 2012, at 1:25 AM, Harris Lapiroff <harrislapir...@gmail.com> > wrote: > >> > >>> The Django admin is a major—if not *the* major—selling point to > >>> budding developers. I worry that externalizing it (hence making it a > >>> *separate* piece of software that needs to be discovered and > >>> installed, which seems simple but can be quite a challenge to new > >>> coders) might take away Django's non-expert appeal. When I started > >>> using Django, I knew no python. The only reason I was able to make > >>> that work was because of the Django admin. If the admin gets kicked > >>> out, I think it should be made *very* obvious where to find one. > >>> > >>> I'd be wary of putting them in core but I think using Bootstrap and > >>> Less for a new admin (whether internal or external) would make its > >>> development much faster. Dependencies should not be a problem. I think > >>> jQuery is a pretty apt analogy here. You probably won't write much > >>> javascript for the Django admin without learning jQuery. You can if > >>> you want to. But most people don't need or want to write javascript > >>> for the Django admin anyway. I think a framework like Bootstrap it > >>> would actually simplify adding new features. It provides so many CSS > >>> classes that there's a pretty good chance your feature wouldn't > >>> require you to write even a line of CSS. I was able to convert an > >>> unstyled app that I've been working on to functionally using Bootstrap > >>> in just about an hour after starting to learn it. > >>> > >>> That having been said, I'd still be cautious with Bootstrap. It is a > >>> young piece of software that is incredibly impressive and mind- > >>> bogglingly easy to use, but obviously still in flux. > >>> > >>> On Feb 2, 5:38 pm, Sean Brant <brant.s...@gmail.com> wrote: > >>>> On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor <alex.gay...@gmail.com> > wrote: > >>>> > >>>>> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty <adr...@holovaty.com> > wrote: > >>>> > >>>>>> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant <brant.s...@gmail.com> > 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 > django-developers@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. > >>>> > >>>>> 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 > django-developers@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. > >>>> > >>>> +1 > >>>> > >>>> Given how flexible the admin is doing somethings is still pretty > >>>> annoying. I feel like if it was a external project with its own > >>>> release schedule more progress could be made. FWIW i'm experimenting > >>>> with an admin interface that relies heavily on class based views. So > >>>> far I like it. CBVs seem to have more useful hooks then the admin > >>>> currently has. At the very least I think the new admin needs to not be > >>>> backwards compatible with the current admin. > >>>> > >>>> So my vote is for django-admin2 as an external project. > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups "Django developers" group. > >>> To post to this group, send email to > django-developers@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. > >>> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Django developers" group. > >> To post to this group, send email to django-developers@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. > >> > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Django developers" group. > >> To post to this group, send email to django-developers@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. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@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. > > -- juanpex -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
