Jeroen Vloothuis wrote: > Afaik there is no proper list. I don't follow dango-users but I'm fine > with also discussing it there.
Yeah, this list is pretty busy! I'll try and keep an eye out for djangorecipe related posts and forward them your way ;-) > I'm curious as to why djangorecipe does its own thing with respect > to downloading Django rather than relying on it as an egg? > > When I started with the recipe Django 1.0 was not released (svn trunk > was the way to go). Another reason was that the Django community was not > that egg happy. Well, I'm certainly not setuptools-happy, but Django appears to be wrapped up as a standard distribution on PyPI (sorry, should have said distro, not egg), so it would make sense to use that... For me, djangorecipe should be some kind of subclass of zc.recipe.egg that just does the extra stuff for Django and creates a (package based) project if one isn't there... > I guess another way of solving this would be console_scripts entry > points. If these are specified in setup.py's of eggs specified in > either the projectegg or eggs options, will they be created by > djangorecipe? > > I'm not sure if that will work with the current code. Since it seems > like a nice feature I would welcome a patch. OK, I'll have a play. > Another solution that has been suggested in the past was to run setup.py > from the download like zc.recipe.egg does. This would make buildout know > about the version that djangorecipe fetched (either from svn or tgz). Yes, this is what I suggested above :-) > Also, is it common practice to have two djangorecipe sections, once > for development and one for production, or is it more common to have > a buildout.cfg and dev.cfg, with dev.cfg extending buildout.cfg? > > The way I use it is with a base.cfg (common stuff for both production > and development), a buildout.cfg which extends base.cfg for development > and then a production.cfg which extends base.cfg (which enables > production settings etc.). Ah, okay, what things do you set in production.cfg and buildout.cfg? (sorry if this is obvious stuff, I'm new to Django) > Finally, it's a shame that the projects generated by the project > option are not eggs :-S Is there any reason for this? > > This would be that I wanted to keep close to the way Django did projects > at that time. I see no reason at this time tho for not having a setup.py > file in the generated project (patches are appreciated :-) I'll see what I can do, but don't hold your breath ;-) (I'm currently following http://jacobian.org/writing/django-apps-with-buildout/ and on a bit of a tight deadline, so don't know when I'll be able to get to this) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
