Re: Multi-tenant Django

2012-05-09 Thread Brett H
Alec,

Mezzanine is using standard django.contrib.sites. Nothing special
there. The main issue with the sites framework is that each site runs
using a separate process and settings, so the resources can add up
depending on how you setup the stack, and managing the tenants becomes
the issue as they grow in number. Apache with modwsgi using self
destructing daemons is the best solution here.

Until https://code.djangoproject.com/ticket/15089 is resolved IMHO
django-hosts is currently the best lightweight solution for multi-
tenancy requirements in django, but not useful with a project like
Mezzanine I'm afraid.

https://github.com/ennio/django-hosts

cheers,

Brett


On May 9, 1:02 pm, Alec Taylor  wrote:
> Dear Django-developers,
>
> I've been using Django for a few months now, and recently—for
> different projects—started using the web-framework: web2py[1], and the
> Django project: mezzanine[2].
>
> Both advertise as being multi-tenant solutions[3][4].
>
> Would it be possible to extend Django to meet this use-case? — Or have
> I overlooked something and is this possible already?
>
> Thanks for all information,
>
> Alec Taylor
>
> [1]http://www.web2py.com/
> [2]http://mezzanine.jupo.org/
> [3]https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw
> [4] PyCon 2012 
> talk:http://youtu.be/M5IPlMe83yI?t=5m32shttp://dl.dropbox.com/u/18065445/Slides/PySFTalkSlides.pdf(slide42,
> see yt for more info)

-- 
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.



Re: Django Admin Revamp - Any updates?

2012-04-30 Thread Brett H
Now that django is on github the best thing that could happen is to
set it free and split it out as a separate django-admin repository
that people can build on, and making site something like site =
load_admin_site(settings.ADMIN_SITE) so that people can do drop in
replacements. Not just that but splitting out the templates and static
assets into a django-admin-originaltheme repository.

In this fashion projects like grappelli can proceed in an opinionated
fashion on making changes to the admin as they see fit but remaining
compatible with the ModelAdmin specifications, and django can pull
back in the consensus commits. Grappelli does a lot of things right,
but now I'm wanting to drop twitter bootstrap in on top of it, and
tomorrow something else might be flavour of the month.

Increasing the flexibility for development and integration is more
important than trying to 2nd guess where we are going to be in 5 years
time.

On Apr 29, 6:13 am, Idan Gazit  wrote:
> As I wrote, I'd like to have a clear idea of what a new admin will accomplish 
> before starting to bolt on enhancements, even great enhancements like 
> grappelli.
>
> The admin was an impressively future-proof design, given that it is still so 
> useful years after it was designed. We should aim to make an admin that will 
> be relevant and useful five years from now; we can't design for that without 
> a couple of clear, simple goals. Grappelli may or may not align with those 
> goals.
>
> -I
>
>
>
>
>
>
>
> On Saturday, April 28, 2012 at 12:55 AM, Daniel Sokolowski wrote:
> > On that note, why can't the fruits of Grappelli be used as a starting point?
>
> > -Original Message-
> > From: h3
> > Sent: Friday, April 27, 2012 4:01 PM
> > To: Django developers
> > Subject: Re: Django Admin Revamp - Any updates?
>
> > I don't know the status of this project, but my guess is that you
> > shouldn't hold your breath for it.
>
> > Fortunately, there is Grappelli:
> >https://github.com/sehmaschine/django-grappelli
>
> > We are currently working on making it compatible with django 1.4 (see
> > the "grappelli_2_4" branch)
>
> > Alternatively the branch on my fork works pretty well with 1.4:
> >https://github.com/h3/django-grappelli/tree/grappelli_2_4
>
> > Cheers
>
> > On Apr 26, 7:06 pm, Victor Hooi  
> > wrote:
> > > Hi,
>
> > > Is there any news on the Django Admin rewrite front?
>
> > > I remember around a year ago, there was quite a bit of talk on revamping
> > > the Django admin UI - I think Idan Gazit was heading that, right?
>
> > > Is that still on the Django roadmap? Any idea of whether it'll be in 1.5,
> > > 1.6, 1.7 etc?
>
> > > Cheers,
> > > Victor
>
> > --
> > 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 
> > (mailto:django-developers@googlegroups.com).
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com 
> > (mailto:django-developers+unsubscr...@googlegroups.com).
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> > Daniel Sokolowski
> > Web Engineer
> > Danols Web Engineering
> >http://webdesign.danols.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-developers@googlegroups.com 
> > (mailto:django-developers@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com 
> > (mailto: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-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.



Re: Cleaning up manage.py and import paths

2011-10-12 Thread Brett H
+1 on installing CWD. Integrates nicely with the virtualenvwrapper
mkproject command.

I have a much longer reasoning why startproject should not get into
creating the outer folder which is effectively the distribution
folder, and the domain of distribution packaging tools, so I'll follow
this post up.

On Oct 13, 11:09 am, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Chris,
>
> On 10/12/2011 05:28 PM, Chris Beaven wrote:
>
> > Great job on getting the ball rolling on this, Carl!
>
> > +1 on the whole idea
>
> Thanks!
>
> > Similar to what Russ and Luke are saying, I'd also prefer it if
> > startproject dropped manage.py and the project Python package in the
> > current working directory (with overwrite checks first).
>
> I remain -1 on CWD pollution by default; I haven't yet seen any
> arguments in favor of it that I find even slightly convincing.
>
> As we just discussed on IRC, I'd be happier to have an optional second
> argument to startproject, if this is really an issue. If two arguments
> were given, the first would be the containing directory name (which
> could also be "."), and the second the package name. (Could also do it
> in the other order, but I think putting the containing directory first
> feels more natural, as it's "first" in the hierarchy).
>
> I'm also fine with ptone's patch to allow using an existing directory,
> which maybe addresses some of the same cases.
>
> I think either one of these should be done as a separate follow-on
> patch, though, as I think they are mostly-orthogonal new features for
> startproject, not closely related to the purpose of this patch.
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6WLCAACgkQ8W4rlRKtE2fK7wCgqnSaF8lHx0/bKcSIb4ElYEJ4
> hdsAn27cKx/j+m0prV9Kz8MptfQR2Dj+
> =GUEr
> -END PGP SIGNATURE-

-- 
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.



Re: Cleaning up manage.py and import paths

2011-10-12 Thread Brett H
Moving the manage.py is a great move.

Post 1.4 you actually might want to think a bit about integrating a
distutils2 setup.cfg into the manage.py folder and the startproject
command.

Since distutils2 will be the standard in python3.3 for packaging and
backported to python 2.5 it makes sense to leverage it for Django.
At the very least the setup.cfg could provide the
DJANGO_SETTINGS_MODULE env variable for installation scripts as a
custom meta-data variable that an installation script could do
something with.

It will probably be good practice to setup a minimal setup.cfg file
anyway with the project name.

My thoughts are that the whole Django project structure existed as a
way to get started quickly, and people replicated it on servers
because python packaging sucked.

Hopefully distutils2 will make it suck a little less and make it
feasible to make Django play nicely with it.

Brett H


-- 
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.



Re: Should user passwords be more strict?

2011-09-14 Thread Brett H
All you need to know about implementing your own policy:

http://xkcd.com/936/

On Sep 14, 1:17 pm, Paul McMillan  wrote:
> I'm happy you're concerned about this, but suggest you search the
> archives for similar material so that new threads can contribute new
> content.
>
> This search is probably a fantastic starting point for your reading 
> pleasure:http://groups.google.com/group/django-developers/search?group=django-...
>
> Regards,
> -Paul
>
>
>
>
>
>
>
> On Tue, Sep 13, 2011 at 3:52 PM, Wim Feijen  wrote:
> > Having just finished a discussion on security, I'd like to raise a
> > concern of mine.
>
> > By default, users can have a one-character password.
>
> > When their accounts get hacked, we suffer the consequences as well.
>
> > Should we be more strict in that?
>
> > Wim
>
> > --
> > 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 
> > 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-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.



Documentation url

2008-10-01 Thread Brett H

I cringe at posting this but.. there's a little forward slash that
suddenly appeared on the Django website documentation url

http://docs.djangoproject.com/en/dev//

Is it just visiting or should I re-bookmark?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---