Re: Status of #1480: "Don't Set TIME_ZONE [...]"

[Gabriel Hurley]

Great! I thought those modifications by "Anonymous" looked funny...

Thanks!

 - Gabriel

On Feb 25, 11:25 pm, Russell Keith-Magee 
wrote:
> On Fri, Feb 26, 2010 at 8:55 AM, Gabriel Hurley  wrote:
> > Having been bitten by issue #1480 personally, I'm wondering what the
> > status of this ticket really is? Trac indicates it needs a better
> > patch and better docs, but there's no information about what changes
> > are needed.
>
> > If someone will give me some guidance, I'd be happy to wrap this one
> > up and see it ship in 1.2...
>
> In this case, I think it's just a matter of spam that hasn't been
> cleaned up properly. Looking at the  history, the 'better patch, needs
> docs, needs tests' flags were all set by an anonymous user, and some
> (but not all) of those flags were reverted very soon after.
>
> The ticket hasn't been committed because the ticket hasn't ever been
> promoted it to ready for checkin, and it's never been put up for
> consideration on a milestone.
>
> From a quick look at the patch, it looks fine; I've marked it ready for 
> checkin.
>
> Yours,
> Russ Magee %-)

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

Re: Django's testing infrastructure

[Stephen Wolff]

We'd like to offer a CentOS 5 machine with Python 2.6 / MySQL 5.0 
(InnoDB and MyISAM) for testing (with Lighttpd 1.4.23 - if that is used 
in any tests). We'll try and set it up over the next week.


Stephen

On 26/02/2010 06:56, Russell Keith-Magee wrote:

On Fri, Feb 26, 2010 at 11:54 AM, Eric Holscher  wrote:
   

Hey everyone,

During the sprints, I worked to set up a hudson instance for Django. This is
hopefully going to be the way that we are going to go forward for now with
doing continuous integration for Django. I have a pretty good setup going
currently, and want make it really fantastic. At this point in time, what we
really need now is some more hardware to be able to run tests on.
 

Great work Eric!

   

So I'm looking for people who can offer other boxes that they would like to
see tested. Currently the big ones we aren't covering are Windows boxes, and
the Oracle backends. There are lots of other permutations that we could be
testing against (Different python runtimes being a good example).
 

Two others to put on this list of unusual platforms that need testing
(in case they aren't on your radar already):

  * MySQL has two configurations that require testing: MyISAM and InnoDB.

  * We also need testing for GIS configurations.

Russ %-)

   


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

Re: Django's testing infrastructure

[Jirka Vejrazka]

Hi Eric,

  great activity, thanks!

  During the EuroDjango spring in Prague, I set up a Ubuntu + Oracle
10g test machine (buildbot) under Jacob's supervision. Shortly after,
Jacob has set up a mailing list for buildbots. However, there were no
followups from either side and my test machine slowly died as I did
poor job maintaining it.

  If there is some traction, I'd be more than happy to
resurrect/reinstall the machine and give you an access to it.

  Cheers

Jirka

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

dbsettings, and user configurable app settings

[Jared Forsyth]

I have been looking around for a way of managing user-configurable
application settings, and the only solution I have found is dbsettings,
which looks like it hasn't been touched in 3 years.
So, I would like to know: is dbsettings dead? Or is there a different
generally accepted method for having user-friendly app settings? (e.g. don't
require code modification)

I think that this idea is pretty essential to django's ease of use; there
are many applications which have (or should have) settings which only effect
UI or minor behavioral issues, and shouldn't require a server restart to
effect (and imo shouldn't require server write access). It seems that the
most viable solution would be to have a database managed settings system (in
the form of a .contrib module) which would manage this. It also seems that
having such an infrastructure in place would really encourage app
maintainers to have more settings, thereby making the apps even more
portable.

Any thoughts?

Thanks,
Jared

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

Re: Django's testing infrastructure

[simonjwoolf]

Hi,

We would be happy to contribute space on one of our staging dedicated
servers.
Our stack is:

CentOS 5
MySQL 5.0 (using InnoDB as standard, but you are welcome to have a
MyISAM database as well)
Python 2.6
Lighttpd 1.4.23

Let me know if this is useful, and perhaps contact me privately to
discuss details of getting it set up.

Simon Woolf
Loopo


On Feb 26, 4:08 am, "Sean O'Connor"  wrote:
> A platform we probably should get into the mix is a CentOS/RHEL 5 box.  I
> suspect a significant portion of the community is stuck on such boxes and
> given the ancient versions of everything available under RHEL I'm sure that
> there are things which will break there and not in a developer's standard
> environment.
>
> I personally don't have a suitable RHEL box laying around but this seems
> like a good candidate for either another volunteer or DSF funds.
>
> 
> Sean O'Connorhttp://seanoc.com
>
> On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher wrote:
>
> > Hey everyone,
>
> > During the sprints, I worked to set up a hudson instance for Django. This
> > is hopefully going to be the way that we are going to go forward for now
> > with doing continuous integration for Django. I have a pretty good setup
> > going currently, and want make it really fantastic. At this point in time,
> > what we really need now is some more hardware to be able to run tests on.
>
> > The current setup is hosted at:http://hudson.djangoproject.com/
>
> > Currently, I have tests running on the following architectures:
>
> > Django trunk:
>
> > Solaris:
> > Python 2.4-2.5
> > Databases: sqlite, postgres, mysql
>
> > Ubuntu:
> > Python 2.5-2.6
> > Databases: sqlite, postgres, mysql
>
> > Django 1.1.X:
>
> > Solaris:
> > Python 2.5
> > Databases: sqlite, postgres
>
> > This gives us pretty good coverage currently, but the whole point of doing
> > CI is that we catch bugs on other platforms we wouldn't normally run on.
>
> > What we need
> > ===
>
> > So I'm looking for people who can offer other boxes that they would like to
> > see tested. Currently the big ones we aren't covering are Windows boxes, and
> > the Oracle backends. There are lots of other permutations that we could be
> > testing against (Different python runtimes being a good example).
>
> > However, we don't want to get in a situation where boxes that people have
> > set up just disappear. So, I'm only currently looking for machines that
> > people would be able to dedicate to the effort. We would require a
> > django-testing user account on the box, with our SSH key on it. There would
> > also be a team of trusted users, who would have access to this key and thus
> > your machine.
>
> > We want the build farm to be stable and useful, and in the past we have had
> > too much trouble having machines just disappear.
>
> > Requirements
> > ===
>
> > Currently the hudson requirements seem to be about <1GB of disk space, with
> > 512MB of ram. I'm also looking into some pony build/barn based alternatives
> > that would knock the memory requirements down pretty substantially. However,
> > for the current 1.2 release it looks like hudson is how we're going to make
> > it going forward.
>
> > Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so
> > another way that we might be able to get this going is to be able to have
> > donations to the DSF, and have them get some dedicated rackspace boxes.
> > However, for now, I'm hoping that we can cobble together enough stuff to get
> > 1.2 tested really well.
>
> > Feedback
> > ==
>
> > If you have any thoughts on CI, or any advice, I would love to hear it. I'm
> > trying to make our Continuous Integration setup really kick ass, so feedback
> > is necessary to do this. I have some notes and ideas that I have been
> > recording while setting things up over at the pycon etherpad:
>
> >http://pyconpads.net/django-testing
>
> > Let me know if you have any thoughts, questions, or concerns.
>
> > Cheers,
> > Eric
>
> >  --
> > 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.

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

Re: IfEqualNode is missing a get_nodes_by_type method

[Russell Keith-Magee]

On Thu, Feb 25, 2010 at 10:33 AM, SmileyChris  wrote:
> My ticket in #6510 [1] deals with this, along with a nice abstraction
> of common recursive nodelist gathering patterns.
>
> Although the ticket description, comments (and even tests in my patch)
> mention {% block %}, this has *nothing* to do with conditional
> inheritance.
>
> If the patch is deemed too much of a feature to fit in the 1.2
> schedule, I'd still advocate for just adding a get_nodes_by_type
> method to the IfEqualNode. It's not a difficult or overly
> controversial change, and the bug has existed far too long because of
> confusion over the actual issue.

I'm a little confused by this ticket.

The original report was about something that is clearly a bug -- the
inconsistency between block handling for {% if %} and {% ifequal %}.
I'm 100% in agreement that this inconsistency should be fixed.

The thing is - it has been. The tests in the patch on #6510 all pass
on current trunk. The refactoring that was required for template
caching has evidently cleaned up this issue - at least enough to
correct the original test case.

So - am I missing something here?

Yours,
Russ Magee %-)

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

Re: Django's testing infrastructure

[Cramet Matthieu]

Wouldn't it be interesting to build some Virtual Machines that people could
grab and deploy directly in the cloud ? It might interest people willing to
contribute hardware but not having much time to dedicate at maintaining it.

I personnaly have a spare Desktop with a Quad Core and 4G of RAM that could
run at leat 4 VMs.

My 2 cents :-D
Matthieu

On Fri, Feb 26, 2010 at 10:45 AM, simonjwoolf <
simonjustinwo...@googlemail.com> wrote:

> Hi,
>
> We would be happy to contribute space on one of our staging dedicated
> servers.
> Our stack is:
>
> CentOS 5
> MySQL 5.0 (using InnoDB as standard, but you are welcome to have a
> MyISAM database as well)
> Python 2.6
> Lighttpd 1.4.23
>
> Let me know if this is useful, and perhaps contact me privately to
> discuss details of getting it set up.
>
> Simon Woolf
> Loopo
>
>
> On Feb 26, 4:08 am, "Sean O'Connor"  wrote:
> > A platform we probably should get into the mix is a CentOS/RHEL 5 box.  I
> > suspect a significant portion of the community is stuck on such boxes and
> > given the ancient versions of everything available under RHEL I'm sure
> that
> > there are things which will break there and not in a developer's standard
> > environment.
> >
> > I personally don't have a suitable RHEL box laying around but this seems
> > like a good candidate for either another volunteer or DSF funds.
> >
> > 
> > Sean O'Connorhttp://seanoc.com
> >
> > On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher  >wrote:
> >
> > > Hey everyone,
> >
> > > During the sprints, I worked to set up a hudson instance for Django.
> This
> > > is hopefully going to be the way that we are going to go forward for
> now
> > > with doing continuous integration for Django. I have a pretty good
> setup
> > > going currently, and want make it really fantastic. At this point in
> time,
> > > what we really need now is some more hardware to be able to run tests
> on.
> >
> > > The current setup is hosted at:http://hudson.djangoproject.com/
> >
> > > Currently, I have tests running on the following architectures:
> >
> > > Django trunk:
> >
> > > Solaris:
> > > Python 2.4-2.5
> > > Databases: sqlite, postgres, mysql
> >
> > > Ubuntu:
> > > Python 2.5-2.6
> > > Databases: sqlite, postgres, mysql
> >
> > > Django 1.1.X:
> >
> > > Solaris:
> > > Python 2.5
> > > Databases: sqlite, postgres
> >
> > > This gives us pretty good coverage currently, but the whole point of
> doing
> > > CI is that we catch bugs on other platforms we wouldn't normally run
> on.
> >
> > > What we need
> > > ===
> >
> > > So I'm looking for people who can offer other boxes that they would
> like to
> > > see tested. Currently the big ones we aren't covering are Windows
> boxes, and
> > > the Oracle backends. There are lots of other permutations that we could
> be
> > > testing against (Different python runtimes being a good example).
> >
> > > However, we don't want to get in a situation where boxes that people
> have
> > > set up just disappear. So, I'm only currently looking for machines that
> > > people would be able to dedicate to the effort. We would require a
> > > django-testing user account on the box, with our SSH key on it. There
> would
> > > also be a team of trusted users, who would have access to this key and
> thus
> > > your machine.
> >
> > > We want the build farm to be stable and useful, and in the past we have
> had
> > > too much trouble having machines just disappear.
> >
> > > Requirements
> > > ===
> >
> > > Currently the hudson requirements seem to be about <1GB of disk space,
> with
> > > 512MB of ram. I'm also looking into some pony build/barn based
> alternatives
> > > that would knock the memory requirements down pretty substantially.
> However,
> > > for the current 1.2 release it looks like hudson is how we're going to
> make
> > > it going forward.
> >
> > > Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so
> > > another way that we might be able to get this going is to be able to
> have
> > > donations to the DSF, and have them get some dedicated rackspace boxes.
> > > However, for now, I'm hoping that we can cobble together enough stuff
> to get
> > > 1.2 tested really well.
> >
> > > Feedback
> > > ==
> >
> > > If you have any thoughts on CI, or any advice, I would love to hear it.
> I'm
> > > trying to make our Continuous Integration setup really kick ass, so
> feedback
> > > is necessary to do this. I have some notes and ideas that I have been
> > > recording while setting things up over at the pycon etherpad:
> >
> > >http://pyconpads.net/django-testing
> >
> > > Let me know if you have any thoughts, questions, or concerns.
> >
> > > Cheers,
> > > Eric
> >
> > >  --
> > > 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-dev

Re: Django's testing infrastructure

[Jacob Kaplan-Moss]

On Fri, Feb 26, 2010 at 10:32 AM, Cramet Matthieu  wrote:
> Wouldn't it be interesting to build some Virtual Machines that people could
> grab and deploy directly in the cloud ? It might interest people willing to
> contribute hardware but not having much time to dedicate at maintaining it.
> I personnaly have a spare Desktop with a Quad Core and 4G of RAM that could
> run at leat 4 VMs.

If you (or anyone else) would be willing to develop some VMs --
VMWare, VirtualBox, or EC2 images would probably be best -- I have
space/bandwidth to host 'em for download. I think it's a fantastic
idea. Especially EC2 instances, actually: if someone does the grunt
work, I think Hudson can boot and manage them directly.

Jacob

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

Re: Django's testing infrastructure

[Steven Elliott Jr]

I have about 4 apple Xserves with quad cores and 16 GBs or RAM sitting  
in my server room at work. I will see if I can use them for this  
purpose. I don't think it will be a problem since I'm the CIO and am  
pretty much left alone to do what i want with our hardware. I'll post  
back next week after I get the ok from the board.


Sent from my iPhone

On Feb 26, 2010, at 11:43 AM, Jacob Kaplan-Moss   
wrote:


On Fri, Feb 26, 2010 at 10:32 AM, Cramet Matthieu  
 wrote:
Wouldn't it be interesting to build some Virtual Machines that  
people could
grab and deploy directly in the cloud ? It might interest people  
willing to
contribute hardware but not having much time to dedicate at  
maintaining it.
I personnaly have a spare Desktop with a Quad Core and 4G of RAM  
that could

run at leat 4 VMs.


If you (or anyone else) would be willing to develop some VMs --
VMWare, VirtualBox, or EC2 images would probably be best -- I have
space/bandwidth to host 'em for download. I think it's a fantastic
idea. Especially EC2 instances, actually: if someone does the grunt
work, I think Hudson can boot and manage them directly.

Jacob

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

Re: Django's testing infrastructure

[Christopher Petrilli]

I can toss in a Core i7 w/12GB for testing as well, if someone can
give me the VMs in either VirtualBox or Linux KVM format. I think this
is a brilliant idea, and would even be willing to contribute some
money to cover EC2/etc, if that's what it takes.

Chris

On Fri, Feb 26, 2010 at 11:49 AM, Steven Elliott Jr
 wrote:
> I have about 4 apple Xserves with quad cores and 16 GBs or RAM sitting in my
> server room at work. I will see if I can use them for this purpose. I don't
> think it will be a problem since I'm the CIO and am pretty much left alone
> to do what i want with our hardware. I'll post back next week after I get
> the ok from the board.
>
> Sent from my iPhone
>
> On Feb 26, 2010, at 11:43 AM, Jacob Kaplan-Moss  wrote:
>
>> On Fri, Feb 26, 2010 at 10:32 AM, Cramet Matthieu 
>> wrote:
>>>
>>> Wouldn't it be interesting to build some Virtual Machines that people
>>> could
>>> grab and deploy directly in the cloud ? It might interest people willing
>>> to
>>> contribute hardware but not having much time to dedicate at maintaining
>>> it.
>>> I personnaly have a spare Desktop with a Quad Core and 4G of RAM that
>>> could
>>> run at leat 4 VMs.
>>
>> If you (or anyone else) would be willing to develop some VMs --
>> VMWare, VirtualBox, or EC2 images would probably be best -- I have
>> space/bandwidth to host 'em for download. I think it's a fantastic
>> idea. Especially EC2 instances, actually: if someone does the grunt
>> work, I think Hudson can boot and manage them directly.
>>
>> Jacob
>>
>> --
>> 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.
>>
>
> --
> 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.
>
>



-- 
| Chris Petrilli
| petri...@amber.org

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

Re: dbsettings, and user configurable app settings

[Wes Winham]

I'd love to see a better way of managing settings in the core of
django. It's a real pain point sometimes for writing and using
pluggable applications and there's a wide range of ways that
application developers try to tackle it. Some have basically no
settings, some plan on users reading the documentation and defining
all required settings, some have a way of using defaults that can be
overridden and some have hacked together ways of using the database
for some settings (I think ReviewBoard does something like this, or
did). The problem I see is that the *best* way hasn't really bubbled
to the surface as far as I can tell. Kind of like how database
migrations are a hard problem, settings management seems kind of
tricky.

Are there things stopping someone from making a really good app for
managing settings and letting that bubble up to the de facto solution
like with South? If there are, maybe removing those things would be a
good target before trying to build the actual solution in contrib. Of
course, this is probably not the best time for discussing this since
everyone is trying to get 1.2 out the door, but I'd love to see this
area improved down the road.

My specific pain points:
 * With a given app, it's a crapshoot to find where they define their
internal settings (some use app/conf/settings.py, some app/conf/
default.py, some app/default.py etc)
 * It's hard to tweak settings on deployment for different
environments. Using a settings_local.py that gets included is a
workable solution, but it requires you to maintain a monolithic file.
Something like the conf.d/*.conf debian style of configuration might

Pinax is having a similar discussion right now. Maybe something will
come out of that project that can be applied/adapted to some later
version of django. That might be a place to apply some development if
anyone is interested in working towards better settings management.
http://groups.google.com/group/pinax-core-dev/browse_thread/thread/d9401468ea3c8edf

-Wes

On Feb 26, 2:11 am, Jared Forsyth  wrote:
> I have been looking around for a way of managing user-configurable
> application settings, and the only solution I have found is dbsettings,
> which looks like it hasn't been touched in 3 years.
> So, I would like to know: is dbsettings dead? Or is there a different
> generally accepted method for having user-friendly app settings? (e.g. don't
> require code modification)
>
> I think that this idea is pretty essential to django's ease of use; there
> are many applications which have (or should have) settings which only effect
> UI or minor behavioral issues, and shouldn't require a server restart to
> effect (and imo shouldn't require server write access). It seems that the
> most viable solution would be to have a database managed settings system (in
> the form of a .contrib module) which would manage this. It also seems that
> having such an infrastructure in place would really encourage app
> maintainers to have more settings, thereby making the apps even more
> portable.
>
> Any thoughts?
>
> Thanks,
> Jared

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

Re: Django's testing infrastructure

[Mikhail Korobov]

That's great news, thanks!

A very minor issue: web server returns 'Content-Type:text/
html;charset=ISO-8859-1' header for this page: 
http://hudson.djangoproject.com/monitor/?
but the actual page encoding is utf-8 so there are strange symbols
instead of translated strings.

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

Re: dbsettings, and user configurable app settings

[Jared Forsyth]

If you look at dbsettings (which again, might be dead - i don't know) it
solves a lot of those problems; settings are tied into the "sites" module,
and are presented to the user in a very friendly way. The problem of db
migration is still there, but I can envision an import/export to XML (or
something) functionality where you can get/transfer all settings (or just
for one/a few apps) to another installation.
I've forked my own copy of dbsettings for the project I'm currently working
on (as I said, it was last touched 2007, and out-of-the-box incompatible),
and improving, so I might try to get it polished and more integrated w/
contrib.admin, and see how it works.

Jared

On Fri, Feb 26, 2010 at 11:00 AM, Wes Winham  wrote:

> I'd love to see a better way of managing settings in the core of
> django. It's a real pain point sometimes for writing and using
> pluggable applications and there's a wide range of ways that
> application developers try to tackle it. Some have basically no
> settings, some plan on users reading the documentation and defining
> all required settings, some have a way of using defaults that can be
> overridden and some have hacked together ways of using the database
> for some settings (I think ReviewBoard does something like this, or
> did). The problem I see is that the *best* way hasn't really bubbled
> to the surface as far as I can tell. Kind of like how database
> migrations are a hard problem, settings management seems kind of
> tricky.
>
> Are there things stopping someone from making a really good app for
> managing settings and letting that bubble up to the de facto solution
> like with South? If there are, maybe removing those things would be a
> good target before trying to build the actual solution in contrib. Of
> course, this is probably not the best time for discussing this since
> everyone is trying to get 1.2 out the door, but I'd love to see this
> area improved down the road.
>
> My specific pain points:
>  * With a given app, it's a crapshoot to find where they define their
> internal settings (some use app/conf/settings.py, some app/conf/
> default.py, some app/default.py etc)
>  * It's hard to tweak settings on deployment for different
> environments. Using a settings_local.py that gets included is a
> workable solution, but it requires you to maintain a monolithic file.
> Something like the conf.d/*.conf debian style of configuration might
>
> Pinax is having a similar discussion right now. Maybe something will
> come out of that project that can be applied/adapted to some later
> version of django. That might be a place to apply some development if
> anyone is interested in working towards better settings management.
>
> http://groups.google.com/group/pinax-core-dev/browse_thread/thread/d9401468ea3c8edf
>
> -Wes
>
> On Feb 26, 2:11 am, Jared Forsyth  wrote:
> > I have been looking around for a way of managing user-configurable
> > application settings, and the only solution I have found is dbsettings,
> > which looks like it hasn't been touched in 3 years.
> > So, I would like to know: is dbsettings dead? Or is there a different
> > generally accepted method for having user-friendly app settings? (e.g.
> don't
> > require code modification)
> >
> > I think that this idea is pretty essential to django's ease of use; there
> > are many applications which have (or should have) settings which only
> effect
> > UI or minor behavioral issues, and shouldn't require a server restart to
> > effect (and imo shouldn't require server write access). It seems that the
> > most viable solution would be to have a database managed settings system
> (in
> > the form of a .contrib module) which would manage this. It also seems
> that
> > having such an infrastructure in place would really encourage app
> > maintainers to have more settings, thereby making the apps even more
> > portable.
> >
> > Any thoughts?
> >
> > Thanks,
> > Jared
>
> --
> 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.
>
>

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

Syndication -- plans to add support for CSS stylesheet?

[intrepidweb]

Hi there,

It would be very helpful to be able to add CSS stylesheets to
syndication feeds. Are there plans for adding this feature in the
future?

Thanks!
Leif

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

Re: Syndication -- plans to add support for CSS stylesheet?

[Andy McKay]

> It would be very helpful to be able to add CSS stylesheets to
> syndication feeds. Are there plans for adding this feature in the
> future?

A search in Trac reveals one ticket added by you:

http://code.djangoproject.com/ticket/12978

Adding a ticket is the right way to go. Adding in a patch for your feature is 
an even better way to go :)
--
  Andy McKay, @clearwind
  http://clearwind.ca/djangoski

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

Re: Django's testing infrastructure

[Eric Holscher]

Awesome response!

Thanks for the offering of support everyone. Luckily, with hudson, it's
pretty simple to get this all set up. We basically just need to figure out
what the infrastructure looks like.

I don't know if it's going to make more sense to try and set up dedicated
Database servers, or try and set up each client to have the necessary
databases running on each one.

Currently, all I need for a slave machine is a box with a publically
accessable IP, with an account with the Django Testmaster's key on it.
Hudson will take care of everything from there, at least on the Django side.

Hudson will ssh in and pull down Java if necessary, then run itself as a
client. It seems we will need to have some kind of standard setup for the
databases, with either local connections being let through without auth, or
with a standard username and password (maybe django/django), so that we can
do the database operations.

If anyone has much experience here, I'll probably be doing some benchmarking
to figure out what kind of app to database server ratio we need, and what
makes sense in that regard.

I'll give this some more thought this weekend, and try and email everyone
who has offered support. I know there is a django-buildbots mailing list
that never got used last time we did this, i dunno if we want to keep the
conversation here and more public, or put it over there and keep the
archives around for setting stuff up.

Thanks again for all the offers, it's really great, now we just need to
figure out how to scale this up without using lots of human hours in the
process.

Cheers,
Eric


On Fri, Feb 26, 2010 at 1:08 PM, Mikhail Korobov wrote:

> That's great news, thanks!
>
> A very minor issue: web server returns 'Content-Type:text/
> html;charset=ISO-8859-1' header for this page:
> http://hudson.djangoproject.com/monitor/?
> but the actual page encoding is utf-8 so there are strange symbols
> instead of translated strings.
>
> --
> 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.
>
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.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 at 
http://groups.google.com/group/django-developers?hl=en.

Inheritance: Create a way to subclass and override attributes of a parent class.

[orokusaki]

Problem that exists:

1) I need to subclass `contrib.auth.User` and strip some of the
elements from it, like making `User.username` non-unique for SAAS with
multiple accounts (`MyCustomUser.username` would only be
`unique_together = ('account', 'username')`

(other instances could occur but I don't pretend to understand the
full implications of this minor limitation)

My proposed solution ( which may be idiotic but I'm looking for
feedback / suggestions ):

1) Allow for subclasses of normal models to override attributes of the
parent model. Then, if any attributes exists that override the parent,
simply use the subclass to create the table and treat the parent as an
ABC adding its attributes ( except ones that were overridden of
course ) into the subclass.

P.S. I know Django is in bug-fix mode but I would like to at least see
what all you guys think so that I can come up with some ideas for this
before 1.3 gets underway.

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

Re: Inheritance: Create a way to subclass and override attributes of a parent class.

[James Bennett]

On Fri, Feb 26, 2010 at 3:26 PM, orokusaki  wrote:
> 1) Allow for subclasses of normal models to override attributes of the
> parent model. Then, if any attributes exists that override the parent,
> simply use the subclass to create the table and treat the parent as an
> ABC adding its attributes ( except ones that were overridden of
> course ) into the subclass.

Strong -1; while dogmatic application of the Liskov Substitution
Principle is something I generally rail against, in this case it's
strongly applicable. Subclasses which don't preserve at least the
public interface of their parents aren't and shouldn't be considered
"subclasses".


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Re: Django's testing infrastructure

[Stephen Wolff]

btw - Simon and I work together - so the identical specs were actually 
one machine... anyhow, we're really pleased to be involved, and to see 
how this all goes. We've been toying with CI for a while - including 
trying out the Trac Bitten plugin (http://bitten.edgewall.org/) - which 
could be another possibility which would tie in with Django's Trac 
instance. I don't think it's quite as mature as Hudson though.


Stephen

On 26/02/2010 20:21, Eric Holscher wrote:

Awesome response!

Thanks for the offering of support everyone. Luckily, with hudson, 
it's pretty simple to get this all set up. We basically just need to 
figure out what the infrastructure looks like.


I don't know if it's going to make more sense to try and set up 
dedicated Database servers, or try and set up each client to have the 
necessary databases running on each one.


Currently, all I need for a slave machine is a box with a publically 
accessable IP, with an account with the Django Testmaster's key on it. 
Hudson will take care of everything from there, at least on the Django 
side.


Hudson will ssh in and pull down Java if necessary, then run itself as 
a client. It seems we will need to have some kind of standard setup 
for the databases, with either local connections being let through 
without auth, or with a standard username and password (maybe 
django/django), so that we can do the database operations.


If anyone has much experience here, I'll probably be doing some 
benchmarking to figure out what kind of app to database server ratio 
we need, and what makes sense in that regard.


I'll give this some more thought this weekend, and try and email 
everyone who has offered support. I know there is a django-buildbots 
mailing list that never got used last time we did this, i dunno if we 
want to keep the conversation here and more public, or put it over 
there and keep the archives around for setting stuff up.


Thanks again for all the offers, it's really great, now we just need 
to figure out how to scale this up without using lots of human hours 
in the process.


Cheers,
Eric


On Fri, Feb 26, 2010 at 1:08 PM, Mikhail Korobov 
mailto:kmik...@googlemail.com>> wrote:


That's great news, thanks!

A very minor issue: web server returns 'Content-Type:text/
html;charset=ISO-8859-1' header for this page:
http://hudson.djangoproject.com/monitor/?
but the actual page encoding is utf-8 so there are strange symbols
instead of translated strings.

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




--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.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 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-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.

Re: Inheritance: Create a way to subclass and override attributes of a parent class.

[orokusaki]

@James

Well, I won't even try to argue with that, but there has to be a way
to conquer problems like this in Django without editing the source
code, don't you think?

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

Re: Inheritance: Create a way to subclass and override attributes of a parent class.

[Jacob Kaplan-Moss]

On Fri, Feb 26, 2010 at 5:11 PM, orokusaki  wrote:
> Well, I won't even try to argue with that, but there has to be a way
> to conquer problems like this in Django without editing the source
> code, don't you think?

There are many, and we've discussed this issue at length any number of
times over the years. Please take the time to read over the history
here; if you've got something new to add to the discussion I'd love to
hear it.

Please keep in mind as a general rule that we're well aware of the
problems Django has. All of us here use Django every day; for each
problem you discover, I could probably recite ten. It doesn't really
help, though, to make a post about each and every problem unless you
can offer specific, actionable solutions.

Remember that code speaks louder than words around here (and in most
open source communities). It's easy to wave our hands around and guess
that a solution could work; a prototype or patch is something else
entirely.

Jacob

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

Re: Inheritance: Create a way to subclass and override attributes of a parent class.

[Jacob Kaplan-Moss]

On Fri, Feb 26, 2010 at 5:17 PM, Jacob Kaplan-Moss  wrote:
> There are many, and we've discussed this issue at length any number of
> times over the years. Please take the time to read over the history
> here; if you've got something new to add to the discussion I'd love to
> hear it.

FTR, here are a few of those threads. These are just the ones I could
find in about 30 seconds of searching the archives; I'm sure there are
more:

* 
http://groups.google.com/group/django-developers/browse_thread/thread/1b18996852d3d1a7
* 
http://groups.google.com/group/django-developers/browse_thread/thread/b8a6cfc59d28b4dc
* 
http://groups.google.com/group/django-developers/browse_thread/thread/f124083c6194dccc

Jacob

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

Re: Inheritance: Create a way to subclass and override attributes of a parent class.

[orokusaki]

@Jacob Thanks for all the links. I appreciate your reply.

Michael

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

Re: Django's testing infrastructure

[Chris Hasenpflug]

On Feb 26, 10:43 am, Jacob Kaplan-Moss  wrote:
> If you (or anyone else) would be willing to develop some VMs --
> VMWare, VirtualBox, or EC2 images would probably be best -- I have
> space/bandwidth to host 'em for download. I think it's a fantastic
> idea. Especially EC2 instances, actually: if someone does the grunt
> work, I think Hudson can boot and manage them directly.

If EC2 is a direction we'd like to go (I think it makes a lot of
sense), I'd be happy to invest some time in building images.  But
don't want it to be for not if the plan is really to stay with always
on machines.

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

Re: Django's testing infrastructure

[Cramet Matthieu]

I don't know i had your message right Chris but i think the purpose is to
keep those machines running for a __long__ time. BUT having VMs ready would
allow anyone to offer a new machine/slice in the case that someone finally
decide to end his participation.

About VMs formats, I am not an expert but i previously used the ones from
Turnkey that can be imported into VMware or Virtualbox and even uploaded to
EC2 or any other cloud service i think.

@Eric : Can you a create a Wiki page somewhere to list the missing
architectures ?

On Sat, Feb 27, 2010 at 7:52 AM, Chris Hasenpflug <
chris.hasenpf...@gmail.com> wrote:

> On Feb 26, 10:43 am, Jacob Kaplan-Moss  wrote:
> > If you (or anyone else) would be willing to develop some VMs --
> > VMWare, VirtualBox, or EC2 images would probably be best -- I have
> > space/bandwidth to host 'em for download. I think it's a fantastic
> > idea. Especially EC2 instances, actually: if someone does the grunt
> > work, I think Hudson can boot and manage them directly.
>
> If EC2 is a direction we'd like to go (I think it makes a lot of
> sense), I'd be happy to invest some time in building images.  But
> don't want it to be for not if the plan is really to stay with always
> on machines.
>
> --
> 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.
>
>

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