Re: PHP-inspired user-friendly in-browser DJango install

2011-09-12 Thread Justine Tunney 
The only reason Drupal is able to do that is because every cheap web hosting
provider supports PHP.  If we made a web gui installer, the only people
who'd be able to use it would be people with root access and they're better
off using apt-get.  There's no way to get people running Django on their
cheap cPanel hosting accounts.

I agree with you that reducing the barriers to using Django is very
important.  But what we need is not necessarily a web based installer, but
something to get people off the ground so they can start playing around with
Django very quickly.  Back in the day (like circa 2004) the thing that
really helped me learn PHP was this program called EasyPHP which was a
simple Windows based installer that got me up and running and writing code
on my local machine in five minutes.

I'd like to see people start up a project for making a Windows installer for
Django that does the following:

- Bundles Python 2.7
- Uses important tools like distribute/pip/virtualenv/fabric
- Installs cygwin or mingw stuff if needed
- Has a simple GUI to do the following: a) ability generate a sqlite django
project skeletons, b) button to start/stop runserver, c) button to show the
site in your web browser, d) button to open a terminal in your project
folder, d) button to open the project folder in the file browser.

Whoever writes this tool could potentially make a lot of money because they
could also write a deployment tool for deploying sites to places like
Gondor.

On Mon, Sep 12, 2011 at 7:54 PM, Alec Taylor  wrote:

> Romain: My main argument is not for n00b developers, but just for any
> nut with a server...
>
> I want to be able to package my DJango project up into something as
> easily installable as a Drupal distribution.
>
> On Tue, Sep 13, 2011 at 4:47 AM, Romain Dorgueil  wrote:
> > Hi,
> >
> > it may be my first message on the list ever, but I wanted to put my 2
> cents
> > here.
> >
> > From the PHP world, Symfony2 introduced a "web installer" system in its
> > "standard" distribution (which is the core + some fancyness).
> >
> > To me, it's useless unless you want to attract people from a larger
> audience
> > than what the framework is aimed at at first. I personally don't want
> some
> > useless (or use-once at best) code to be around my project, and I don't
> > think it's the role of a developper-oriented piece of software to provide
> > such things. Of course, a more "newbie-friendly" may be "nice-to-have",
> but
> > imho the "core" of a framework should not provide such thing.
> >
> > Romain.
> >
> > On 12/09/2011 18:39, Tom Evans wrote:
> >>
> >> On Fri, Sep 9, 2011 at 4:56 PM, Alec Taylor
> >>  wrote:
> >>>
> >>> Looks useable.
> >>>
> >>> Anyone interested in working with me to port this to DJango?
> >>
> >> Alec, as other people have mentioned, Django is not Drupal. Drupal is
> >> a web application that can be customized using plugins, where as
> >> Django is a python library one can use to create web applications.
> >> With that in mind, 'porting this to django' is nonsensical - PyLucid
> >> uses Django already, and Django is only the framework, not the
> >> project.
> >>
> >> The point here is that two different web apps created using Django
> >> could have vastly different requirements and installation steps, where
> >> as Drupal has a single set of steps to go from nothing to installed.
> >>
> >> In fact, its quite common to have the same project installed and
> >> running in completely different manners. For instance on our
> >> production servers, all libraries/code/templates, even in house ones,
> >> are installed from our internal package repository (an in house pypi
> >> clone), where as in development, each package is checked out from
> >> subversion in an editable form.
> >>
> >> PyLucid is a good example of a project based on django providing
> >> simple and clean installation instructions - although I wouldn't
> >> deploy it quite like that myself, any solution which uses .htaccess is
> >> Bad and Wrong imo*.
> >>
> >>> (the reason I'm not doing it myself is that I am very new to Python and
> >>> DJango)
> >>>
> >> And (not to be too harsh) this is why you are suggesting it. Django is
> >> like a tool, admittedly it's one of those Leatherman style multi tools
> >> that you can use to do almost anything, but it's still a tool for you
> >> to use rather than a base.
> >>
> >> Cheers
> >>
> >> Tom
> >>
> >> * de gustibus non est disputandum
> >>
> >
> > --
> > 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

Re: plea for re-opening ticket 13125 marked as won't fix

2011-09-12 Thread Justine Tunney 
Here's an idea that might work better than a decorator:

Create a setting called ALLOW_DEACTIVATED_LOGINS.  Then modify auth.login()
to enforce this as well as changing ModelBackend.get_user() to logout users
whose accounts are disabled.  Make the setting True by default in 1.4 and
announce it'll be set to False in either 1.5 or 1.6.

This way is_active can be secure by default, not require users to implement
its functionality themselves while also following the principle of least
astonishment.  The only confusing this about this solution is that users
might not understand it doesn't affect the admin login form and
auth.views.login

On Mon, Sep 12, 2011 at 3:43 AM, Florian Apolloner wrote:

> Probably yeah, on the other hand the docs tell you that is_active doesn't
> neccessarily have to be checked by backends, so if a backend allows to login
> inactive users it makes no sense to check that flag in login_required… I
> guess what I am proposing is that the login_required flag checks via the
> auth backends whether or not the user should be allowed to pass, that way
> all the neccessary checks stay in one place…
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/A922lTjpZc8J.
>
> 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.