I tried buildout with djangorecipe yesterday for the first time and everything worked just fine, today I get the "Error: Couldn't install: djangorecipe 0.17.2". Please help.

Imported from Launchpad using lp2gh.

• date created: 2009-04-25T10:04:19Z
• owner: ckrybus
• the launchpad url was https://bugs.launchpad.net/bugs/366634

I have an egg called "MyEgg", which has a package called "mypackage" with a settings.py file inside. Right now djangorecipe will append the egg name in front of the settings filename, instead of getting a full package + module pointer.

Imported from Launchpad using lp2gh.

• date created: 2009-11-25T20:26:57Z
• owner: tiberiu-ichim
• the launchpad url was https://bugs.launchpad.net/bugs/488421

Could you explain me how I can use the django development version with djangorecipe?
There is a comment in the djangorecipe documents that says that mr.developer should be used, but an example buildout that uses djangorecipe and the django development version would be very helpful.

Thanks,
Maarten

using the following configuration in my buildout.cfg

[django]
recipe = djangorecipe==0.9.1
settings = settings
test=django
project = tsi
version = http://code.djangoproject.com/svn/django/trunk@7943
wsgi = True
eggs =
${libraries:eggs}

djangorecipe still checks out the HEAD revision of trunk:

Installing django.
At revision 8053.

Imported from Launchpad using lp2gh.

• date created: 2008-07-22T12:59:15Z
• owner: shanx
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/250811

It is currently not possible to place the project directory into a 'src' subdirectory.
e.g src/myproject instead of myproject
I added an experimental fix to this problem in https://code.launchpad.net/~stefanfoulis/djangorecipe/subdir

Imported from Launchpad using lp2gh.

• date created: 2009-12-31T20:02:43Z
• owner: stefanfoulis
• the launchpad url was https://bugs.launchpad.net/bugs/501964

The urls.py that is generated by djangorecipe does not work with Django trunk. (Or any version of Django > 1.0?)

When you hit http://127.0.0.1:8000/admin/ a 500 error is thrown:
AttributeError at /
'AdminSite' object has no attribute 'root'

The fix is to update ~jvloothuis/djangorecipe/trunk/files/head:/src/djangorecipe/urls.py at line 127 to say:
...
(r'^admin/(.*)', include(admin.site.urls)),
...

I'm not including a patch because I'm not sure how you'd like to handle backwards compatibility -- also, this seems like something that would have been found a long time ago and I can't help but think I'm missing something.

Imported from Launchpad using lp2gh.

• date created: 2010-11-07T18:20:44Z
• owner: sbc
• the launchpad url was https://bugs.launchpad.net/bugs/672220

Our Django project uses Celery to start asynchronous tasks. Celery 2 now requires the following addition to the WSGI script:

os.environ["CELERY_LOADER"] = "django"

Bug #338735 is about adding code injection into the WSGI script, which would be the best way to add this piece of code. In the mean time, though, would it be possible to just always add this line? It does no harm if Celery is not used.

Imported from Launchpad using lp2gh.

• date created: 2010-07-05T09:59:24Z
• owner: jcassee
• the launchpad url was https://bugs.launchpad.net/bugs/601839

Why Django is not installed as egg, but instead added to parts?

This leads to dependency checking errors if a package requires django...

In other words, for other packages it is not possible to check if django is installed, because it is simply added to parts and to pythonpath.

Imported from Launchpad using lp2gh.

• date created: 2011-05-18T11:49:14Z
• owner: sirex
• the launchpad url was https://bugs.launchpad.net/bugs/784543

Sometimes it takes quite long to download or update django. A message would be good here. The following patch adds this.

Imported from Launchpad using lp2gh.

• date created: 2008-08-23T11:16:49Z
• owner: erevilla
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/260628

I've added the django-staticfiles add-on (http://pypi.python.org/pypi/django-staticfiles), which adds a "build_static" subcommand.

It does not show up in the bin/django command as generated by djangorecipe. "bin/django help" does not list it and "bin/django build_static" gives "Unknown command: 'build_static'"

I'll start digging into this myself later this week unless I missed something obvious.

For completeness sake the contents of my bin/django::

#!/usr/bin/python

import sys
sys.path[0:0] = [
'/home/reinout/svn/nens/lizard-ui',
'/home/reinout/.buildout/eggs/djangorecipe-0.20-py2.6.egg',
'/home/reinout/.buildout/eggs/zc.recipe.egg-1.2.2-py2.6.egg',
'/home/reinout/.buildout/eggs/zc.buildout-1.4.3-py2.6.egg',
'/home/reinout/.buildout/eggs/django_staticfiles-0.2.0-py2.6.egg',
'/home/reinout/svn/nens/lizard-ui/parts/django',
'/home/reinout/.buildout/eggs/distribute-0.6.10-py2.6.egg',
'/home/reinout/svn/nens/lizard-ui/parts/django',
'/home/reinout/svn/nens/lizard-ui',
]

import djangorecipe.manage

if name == 'main':
djangorecipe.manage.main('lizard_ui.testsettings')

Imported from Launchpad using lp2gh.

• date created: 2010-03-01T14:43:54Z
• owner: reinout
• the launchpad url was https://bugs.launchpad.net/bugs/530066

djangorecipe creates a project specified in the 'project' option in buildout.cfg. It would be very useful to be able to specify an existing egg as your django project. I may have time to implement this if you like the idea.

Imported from Launchpad using lp2gh.

• date created: 2008-07-28T17:04:10Z
• owner: danfairs
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/252647

When both projectegg and wsgi=True are specified, the generated wsgi file does not have the correct settings file in it. Attached patch fixes this. (Note - can't seem to run the tests any more, where does 'mock' come from?)

Imported from Launchpad using lp2gh.

• date created: 2008-09-01T17:31:11Z
• owner: danfairs
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/263705

The return line from Recipe.install returns a list of created files + options['location']:

    return script_paths + [location]

Location, in my case is BUIDLOUT_FOLDER/parts/django . However with my config, the location is not created (as it is not needed). Returning it to buildout causes buildout to continuously think it is missing an output file. This causes it for the part to be uninstalled and re-installed every run.

Changing the return line to read:

    return script_paths

works perfectly fine and solves the issue.

For reference, my config is:

[django]
recipe = djangorecipe
wsgi = True
projectegg = DjangoSite
settings = settings
eggs = BrandMonitor

Cheers,
Boaz

There is a missing 'import sys' statement when using wsgi = true and logfile option in django.wsgi.

Imported from Launchpad using lp2gh.

• date created: 2009-10-14T07:56:09Z
• owner: anaberan
• the launchpad url was https://bugs.launchpad.net/bugs/451065

Django manage.py test has a --noinput option in case the user is running tests from an automated script. In my case, I'm running the djangorecipe-generated tests from fabric.

Excerpt from the Django documentation (http://docs.djangoproject.com/en/1.0/ref/django-admin/#test):
    Use the --noinput option to suppress all user prompting, such as "Are you sure?" confirmation messages. This is useful if django-admin.py is being executed as an unattended, automated script.

Imported from Launchpad using lp2gh.

• date created: 2009-11-07T16:58:23Z
• owner: jonasnockert
• the launchpad url was https://bugs.launchpad.net/bugs/477587

Here is an error output generated by "buildout -v":

-8<--
Installing 'djangorecipe'.
We have no distributions for djangorecipe that satisfies 'djangorecipe'.
Getting distribution for 'djangorecipe'.
We have the best distribution that satisfies 'setuptools'.
Picked: setuptools = 0.6c9
Running easy_install:
/usr/bin/python2.5 "-c" "from setuptools.command.easy_install import main; main()" "-mUNxd" "/home/xxx/yyy/eggs/tmpIiKhWL" "-q" "/home/xxx/yyy/downloads/dist/djangorecipe-0.12.tar.gz"
path=/home/xxx/yyy/eggs/setuptools-0.6c9-py2.5.egg

error: /tmp/easy_install-E0ZhlZ/djangorecipe-0.12/CHANGES.txt: No such file or directory
An error occured when trying to install djangorecipe 0.12.Look above this message for any errors thatwere output by easy_install.
While:
Installing.
Getting section django.
Initializing section django.
Installing recipe djangorecipe.
Getting distribution for 'djangorecipe'.
Error: Couldn't install: djangorecipe 0.12
-8<--

Imported from Launchpad using lp2gh.

• date created: 2008-09-29T02:23:19Z
• owner: marek-kuziel-encode
• the launchpad url was https://bugs.launchpad.net/bugs/275668

When the bin/django script is generated, it uses the Python that was used to run the buildout script. It should use whatever Python is available in the current environment.

For example, currently the bin/django script starts with (in my case):

!/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6

Some of the other generated scripts (such as the wsgi script) start with:

!/usr/bin/env python

This uses whatever Python is currently available.

My current buildout script creates not only my Django environment, but also the virtualenv to be used, but when I enter that virualenv (python2.6/bin/activate) Django continues to use the system-wide python instead of the local Python as it should.

Imported from Launchpad using lp2gh.

• date created: 2009-04-15T13:02:52Z
• owner: joe-kueser
• the launchpad url was https://bugs.launchpad.net/bugs/361695

First of all I've created:
virtualenv --no-site-packages --python=2.6 ENV
then after runing python bootstrap.py everything is fine, but after runing bin/buildout I can see that SVN is trying to CO trunk version of djago but it hangs and nothing is happening. After CTRL+C those errors appears:
svn: Could not save the URL of the version resource
svn: Caught signal
Next I've used bin/buildout -v and everything works just fine. Most of the users on #django-pl has the same problem.

Imported from Launchpad using lp2gh.

• date created: 2009-05-11T22:00:06Z
• owner: burc
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/375151

django.core.management.execute_manager is deprecated in Django1.4.

The new djangorecipe.manage (dropping support for older Django versions) could be like this:

import os
import sys
from django.core import management

def main(settings_file):
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', settings_file)
    management.execute_from_command_line(sys.argv)

To support also other Django versions, I suggest this:

import sys
import django
from django.core import management


def main(settings_file):
    if django.VERSION[0:2] >= (1, 4):
        # In Django 1.4 manage.py changed a bit
        import os
        os.environ.setdefault('DJANGO_SETTINGS_MODULE', settings_file)
        management.execute_from_command_line(sys.argv)
    else:
        try:
            mod = __import__(settings_file)
            components = settings_file.split('.')
            for comp in components[1:]:
                mod = getattr(mod, comp)

        except ImportError:
            # XXX: Hack for python < 2.6
            _, e, _ = sys.exc_info()
            sys.stderr.write("Error loading the settings module '%s': %s"
                                % (settings_file, e))
            sys.exit(1)

        management.execute_manager(mod)

I could prepare a pull request for this, but creating a new fork only for this seems too much :-)

Wouldn't it be wise ?

recipe.py

def update(self):
    newest = self.buildout['buildout'].get('newest') == 'true'

    if newest and (not self.install_from_cache and \
            self.is_svn_url(self.options['version'])):
        self.svn_update(self.options['location'], self.options['version'])

Imported from Launchpad using lp2gh.

• date created: 2009-05-19T13:03:54Z
• owner: vinilios
• the launchpad url was https://bugs.launchpad.net/bugs/378319

I used the example buildout.cfg but I get the error below. I got further when I set djangorecipe==0.8 and version == trunk. I created the missing directories just in case and it's not a permissions problem AFAIK. It worked fine when I pulled the trunk from bzr and did a setup.py install. The dummyshop only show links to admin and media for me :(

I'm new to buildout but I know python & linux.

James

james@t61jc:~/src/python/buildout$ uname -a
Linux t61jc 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

james@t61jc:~/src/python/buildout$ buildout
Getting distribution for 'djangorecipe'.
error: /tmp/easy_install-9P1nPQ/djangorecipe-0.9/CHANGES.txt: No such file or directory
An error occured when trying to install djangorecipe 0.9.Look above this message for any errors thatwere output by easy_install.
While:
Installing.
Getting section django.
Initializing section django.
Installing recipe djangorecipe.
Getting distribution for 'djangorecipe'.
Error: Couldn't install: djangorecipe 0.9
j

Imported from Launchpad using lp2gh.

• date created: 2008-07-04T14:42:19Z
• owner: seamas
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/245542

When an SVN revision is specified, the recipe still removes Django, runs svn update and installs Django again. This could be skipped if the revision number in the buildout config is unchanged.

Imported from Launchpad using lp2gh.

• date created: 2009-04-28T08:06:27Z
• owner: bramd
• the launchpad url was https://bugs.launchpad.net/bugs/368430

I ran into a small problem where the order of the sys.path components was relevant and I noticed that the generated django.wsgi script appends the local components while bin/django prepends them. IMO local path components should be prepended in both cases.

Tested with zc.buildout 1.2.1

Imported from Launchpad using lp2gh.

• date created: 2009-05-01T16:02:33Z
• owner: zerok
• assignee: jezdez
• the launchpad url was https://bugs.launchpad.net/bugs/370420

Currently, I set version to ${versions:django} to keep all my versions in one place. For backwards compatibility djangorecipe could fallback to the versions part:django if no version is specified. This behavior still allows you to specify a specific version for a django part, to test multiple versions for example.

Imported from Launchpad using lp2gh.

• date created: 2009-12-20T12:50:28Z
• owner: bramd
• the launchpad url was https://bugs.launchpad.net/bugs/498771

Ran bootstrap and bin/buildout, but bin/test gives some error output, but seems to run OK. Known problem?

$ bin/test
Running zope.testing.testrunner.layer.UnitTests tests:
Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
/bin/sh: spamspamspameggs: not found
Error loading the settings module 'cheeseshop.tilsit': No module named tilsitError loading the settings module 'cheeseshop.tilsit': No module named tilsit Ran 37 tests with 0 failures and 0 errors in 0.038 seconds.
Tearing down left over layers:
Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

Imported from Launchpad using lp2gh.

• date created: 2010-03-01T15:01:40Z
• owner: reinout
• the launchpad url was https://bugs.launchpad.net/bugs/530080

We now use an in office fileserver for storing all of our repo's, the repo's are reachable through svn+ssh on a non standard port. This can be configured to work in subversion by adding a tunnel in the ~/.subversion/config file so instead of the normal svn+ssh part in the url one can for example have repo's like: svn+maykin://myproject in which the maykin part already specifies user and port in the subversion config. Very handy :P

But djangorecipe unfortunately cannot use these kind of url's yet, this patch add's that functionality to djangorecipe.

Cheers!
Remco

Imported from Launchpad using lp2gh.

• date created: 2009-02-09T17:33:03Z
• owner: shanx
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/327275

If youre behind a proxy djangorecipe cant download django:

File "/export/home/p950dia/proj/inv.zc/eggs/djangorecipe-0.17.1-py2.4.egg/djan
gorecipe/recipe.py", line 327, in get_release
File "/usr/lib/python2.4/urllib.py", line 89, in urlretrieve
return _urlopener.retrieve(url, filename, reporthook, data)
File "/usr/lib/python2.4/urllib.py", line 222, in retrieve
fp = self.open(url, data)
File "/usr/lib/python2.4/urllib.py", line 190, in open
return getattr(self, name)(url)
File "/usr/lib/python2.4/urllib.py", line 313, in open_http
h.endheaders()
File "/usr/lib/python2.4/httplib.py", line 818, in endheaders
self._send_output()
File "/usr/lib/python2.4/httplib.py", line 699, in _send_output
self.send(msg)
File "/usr/lib/python2.4/httplib.py", line 666, in send
self.connect()
File "/usr/lib/python2.4/httplib.py", line 632, in connect
socket.SOCK_STREAM):
IOError: Errno socket error

In recipe.py urllib2 that handles proxy settings transparently should be used instead of urllib

Imported from Launchpad using lp2gh.

• date created: 2009-04-17T09:38:45Z
• owner: p-feedem
• the launchpad url was https://bugs.launchpad.net/bugs/362822

Suppose you have a buildout.cfg like so:

[buildout]
parts = django
versions = versions

[django]
recipe = djangorecipe
version = 1.1
projectegg = myproject
eggs = my.egg.dep

[versions]
my.egg.dep = 1.2.3

When you first run buildout, the django script will have my.egg.dep-1.2.3 in it's path. If you change the buildout.cfg [versions] section to be "my.egg.dep = 1.2.5" and rerun buildout, the django script will continue to point to my.egg.dep-1.2.3 in it's path instead of the new version requirement of my.egg.dep-1.2.5.

The workaround for this bug is to delete the .installed.cfg file in the buildout directory before running buildout. This will force buildout to run the install method for all recipes.

Imported from Launchpad using lp2gh.

• date created: 2009-10-08T18:48:49Z
• owner: pcardune
• the launchpad url was https://bugs.launchpad.net/bugs/446584

Is support for Django 1.4 being planned?

The [versions] has no description whatsoever. It should tell if there is a way to try retrieve the latest stable 1.3x version for example and how 1.3 differs from 1.3.0.

Hi! Maybe I miss some buildout magic, but I didn't find a way to use Django system installation.
That would be nice option for some deployment strategies.

The untarred_dir is incorrectly set. We need to define a filter to know exactly which folder was included in the tgz.

Have a look at the patch which also includes:

• using offline version (don't update svn if offline)
• logging

This may not apply cleanly as we had local changes.

Imported from Launchpad using lp2gh.

• date created: 2008-08-21T15:07:06Z
• owner: erevilla
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/260097

Hecko, good sir,

Your recipe has served me wonderfully with Django 1.2 to 1.3.1, but now I’m in the process of upgrading my project to Django 1.4, and I’m running into a problem.

$ bin/django 
Error loading the settings module 'yoursiblings.development': Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.

The new default manage.py sets the environment variable DJANGO_SETTINGS_MODULE, as described here. When I do this manually, the error vanishes as would be expected.

DJANGO_SETTINGS_MODULE=yoursiblings.development bin/django

I hope this is not just a misconfiguration on my part, and that, if it is not, you’ll easily be able to update the recipe.

Many thanks,
Telofy

I would like to suggest the attached patch.

so usefull when debugging apache/wsgi/django/missing dependencies

Imported from Launchpad using lp2gh.

• date created: 2011-08-25T17:21:32Z
• owner: b.clermont
• the launchpad url was https://bugs.launchpad.net/bugs/833949

Djangorecipe uses pythonpath in the buildout config where most other recipes uses extra-paths

Example, to add mock to the django & django.wsgi paths with djangorecipe you would add the following line to the django section of buildout

pythonpath = ${mock:location}/mock-${versions:mock}

Whereas in most recipes one would do:

extra-paths = ${mock:location}/mock-${versions:mock}

Maybe it is a good idea to stick to the defacto extra-paths?

Imported from Launchpad using lp2gh.

• date created: 2008-09-16T14:10:29Z
• owner: shanx
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/270908

when running the bootstrap code I get this error:

python bootstrap.py

Traceback (most recent call last):
File "bootstrap.py", line 36, in
exec urllib2.urlopen('http://nightly.ziade.org/distribute_setup_dev.py'
[... snip ..]
urllib2.HTTPError: HTTP Error 404: Not Found

Replacing bootstrap.py with the one from http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py seems to fix the problem.

Imported from Launchpad using lp2gh.

• date created: 2009-12-31T18:57:55Z
• owner: stefanfoulis
• the launchpad url was https://bugs.launchpad.net/bugs/501954

I am creating a buildout that uses django via djangorecipe, but also some other eggs that require 'django>=1.0'.

When the eggs begin to install, the django install fetched by djangorecipe does not satisfy that dependency, so buildout will download the newest version of django from PyPI, overriding what's fetched by djangorecipe.

It seems the problem can be fixed by installing the checkout as a develop-egg, and I have attached a quick, hacky patch I did that seemed to fix my issue. I'm not really very familiar with buildout recipes, so I might be flying in the face of some really basic guidelines here, but it did at least let my django project build and run.

Imported from Launchpad using lp2gh.

• date created: 2009-07-10T14:31:27Z
• owner: ircubic
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/397864

I have Django 1.1 installed in Windows. I am using buildout to create a Django installation using Django 1.2.

The generated sys.path in django.wsgi-script.py (and the other scripts) has this:

'c:\python26\lib\site-packages',
'c:\home\dhat\webapps\portal-1.0\myproject\parts\django',

which makes the new installation use the system Django, not the buildout version needed.
If I reorder those 2 lines it works correctly.

Here's my buildout.cfg:

[buildout]
parts = python django django-patches css dojo
develop = .
eggs = django-notify
dojango
django-maintenancemode
xlrd
xlwt
titlecase
portal_python = 2.6
portal_django = 1.2
dojango_version = dojango-0.4.6-py${buildout:portal_python}
dojo_version = 1.4.2
download-cache = ${buildout:directory}..\download-cache

[python]
recipe = zc.recipe.egg
interpreter = python
eggs = ${buildout:eggs}

[django]
recipe = djangorecipe
version = ${buildout:portal_django}
project = myproject
projectegg = myproject
settings = settings
wsgi = true

wsgilog = ${buildout:directory}\var\rp.log

extra-paths = ${buildout:directory}..
${buildout:directory}\portal
eggs = ${buildout:eggs}
test = portal
events

[django-patches]

fix for Django ticket 11797

support Dojo 1.4 in Dojango

recipe = iw.recipe.cmd
on_install = true
on_update = true
cmds =
copy ${buildout:directory}\patches\1.2\client.py ${buildout:directory}\parts\django\django\test
copy ${buildout:directory}\patches\dojango\conf\settings.py ${buildout:directory}\eggs\dojango-0.4.6-py2.6.egg\dojango\conf

[css]
recipe = iw.recipe.cmd
on_install = true
on_update = true
cmds =
mkdir ${buildout:directory}..\var
mkdir ${buildout:directory}\var
mkdir ${buildout:directory}\var\django_cache
mkdir ${buildout:directory}\var\django_sessions
mkdir \home\dhat\portal\rp
mkdir \home\dhat\portal\rp\teacher
mkdir \home\dhat\portal\admin
xcopy ${buildout:directory}\rp* \home\dhat\portal\rp /E /D /Y
copy ${buildout:directory}\config${buildout:portal}\settings_local.py ${buildout:directory}
copy ${buildout:directory}\bin\django.wsgi-script.py ${buildout:directory}..\myproject.wsgi

[dojo]
recipe = hexagonit.recipe.download
strip-top-level-dir = true
destination = ${buildout:directory}/eggs/${buildout:dojango_version}.egg/dojango/dojo-media/src/${buildout:dojo_version}
url = http://download.dojotoolkit.org/release-${buildout:dojo_version}/dojo-release-${buildout:dojo_version}-src.tar.gz

Imported from Launchpad using lp2gh.

• date created: 2010-05-19T19:54:13Z
• owner: myersjj
• the launchpad url was https://bugs.launchpad.net/bugs/583033

Version 0.20

Specifying a url or "trunk" as the version attribute of djangorecipe generates an svn command on line 251 of recipe.py:

cmd = 'svn co %s %s' % (svn_url, download_location)

If the project name / path contains any spaces, these do not get quoted or escaped, so the svn command sees the extra path parts as invalid command options. The fix is to quote the parameters, changing the line to:

cmd = 'svn co "%s" "%s"' % (svn_url, download_location)

Imported from Launchpad using lp2gh.

• date created: 2010-03-11T22:21:26Z
• owner: mail-4brad
• the launchpad url was https://bugs.launchpad.net/bugs/537719

I want to use the djangorecipe's manage.py wrapper and the test script in a new
created django app.

I have the following directory structure:

src/
    app/
        __init__.py
        tests.py
buildout.cfg
testsettings.py

And here is the django part of my buildout.cfg:

[django]
recipe = djangorecipe
version = 1.1.1
project = app
projectegg = app
settings = testsettings
test = app
eggs =
extra-paths =
src

Unfortunatelly djangorecipe will fail here. It will not find my settings file
correctly, because it always prepends the settings module name with the project
name which results in app.testsettings in this case. This not a good
behaviour and is limiting my project layout. Ofcourse i considered moving the
testsettings.py file into the app direcotry, but I think it is no good habit
for a django app to ship with its own settings file.

Just give me nice hint if I have overlooked an option that makes djangorecipe
behave the way which is needed in this case.

Imported from Launchpad using lp2gh.

• date created: 2009-11-18T01:51:39Z
• owner: gregor-muellegger
• the launchpad url was https://bugs.launchpad.net/bugs/484572

I the documentation says: "projectegg: Use this instead of the project option when you want ..."

But in the generated tests scripts the projectegg is ignored.

My buildout configuration:
"""
[buildout]
parts =
django
extras

newest = false
prefer-final = true

extensions = mr.developer
sources = sources

auto-checkout =
finances
contas

eggs =
ipython
ipdb
south
Werkzeug
finances
contas
django_nose

[extras]
recipe = iw.recipe.subversion
urls =
http://django-command-extensions.googlecode.com/svn/trunk/ django-command-extensions

[django]
recipe = djangorecipe
version = 1.2.3
settings = development

project = finances

projectegg = finances
wsgi = true
eggs =
${buildout:eggs}

extra-paths =
${extras:location}/django-command-extensions/

test = contas
testrunner = django_nose.NoseTestSuiteRunner

[sources]
finances = hg /Users/lucianopacheco/src_rm/lucmult/web_finances/tmp/finances # the project
contas = hg /Users/lucianopacheco/src_rm/lucmult/web_finances/tmp/contas # the application
""

The workaround is use both "project" and "projectegg" options.

I'll submit a patch

Imported from Launchpad using lp2gh.

• date created: 2010-09-12T01:06:28Z
• owner: lucmult
• the launchpad url was https://bugs.launchpad.net/bugs/636108

This happens because is_svn_url() returns 0 whenever it is called inside an svn-versioned directory.

$ ls -A
.svn  branches tags  trunk
$ svn info 1.0
1.0:  (Not a versioned resource)
$ echo $?
0

Since the documented version specs are 'trunk', a version number, or a full url, is_svn_url() could be something like

return version == 'trunk' or is_valid_url(version)

Off the top of my head, I don't know what is_valid_url() would look like.

Imported from Launchpad using lp2gh.

• date created: 2008-09-17T01:54:12Z
• owner: me-jeffbalogh
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/271145

In: https://github.com/rvanlaar/djangorecipe/blob/master/src/djangorecipe/recipe.py

The location option is set based on the parts-directory. Djangorecipe of course used to install django into the parts directory <= 0.23.1. But now that djangorecipe uses a dependency on Django, location points nowhere:

 23         options['location'] = os.path.join(
 24             buildout['buildout']['parts-directory'], name)

We use location for patching Django when required, eg.:

[patch.django]
recipe = collective.recipe.patch
eggs = ${buildout:eggs}
path = ${django:location}
patches = var/patches/django-add-view-permission-to-user-model.diff

I would love to contribute a patch for this, but don't know what would be the right way to fix this. Any thoughts?

Right now djangorecipe specifies only "outlog" and "errlog" keyword arguments when calling runfastcgi() which can be suboptimal.
For example by default runfastcgi() uses method='prefork' which leads to the increased memory usage.

djangorecipe should provide some way to specify custom runfastcgi() options

For example use some variable defined in the project settings. I think it's a good place for fastcgi options. Djangorecipe already provides a facility to use one of available settings modules.

I slightly modified djangorecipe and made following changes to djangorecipe/fcgi.py (the same as attached diff):

diff --git a/src/djangorecipe/fcgi.py b/src/djangorecipe/fcgi.py
index 10eef4e..e814d2b 100644
--- a/src/djangorecipe/fcgi.py
+++ b/src/djangorecipe/fcgi.py
@@ -16,7 +16,9 @@ def main(settings_file, logfile=None):
# Setup settings
management.setup_environ(mod)

• options = {}
• from django.conf import settings

• options = getattr(settings, 'FASTCGI_OPTIONS', {})
  if logfile:
  options['outlog'] = logfile
  options['errlog'] = logfile

In settings.py I've added:

FASTCGI_OPTIONS = {
'method': 'threaded',
}

It works for me.

Please consider using this diff, or provide some other way to specify custom fastcgi options.

Imported from Launchpad using lp2gh.

• date created: 2009-12-03T17:33:04Z
• owner: redvasily
• the launchpad url was https://bugs.launchpad.net/bugs/492005

When using a username in the SVN url like: http://user@testing/trunk@2531 the current way of searching for the revision breaks. Not a big deal when using the main django svn, but not very handy when you have django in private subversion repos. The patch fixes this by using a regular expresssion.

Imported from Launchpad using lp2gh.

• date created: 2008-09-24T14:43:12Z
• owner: shanx
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/274004

urls.py hasn't been updated for the new admin

Imported from Launchpad using lp2gh.

• date created: 2008-09-30T10:18:44Z
• owner: roland-micite
• assignee: roland-micite
• the launchpad url was https://bugs.launchpad.net/bugs/276255

so say you need to initialize a library, or monkeypatch ( django_localeurl) or want to wrap the django wsgi handler in middleware.

the wsgi stub presents the best place to do so, i propose an option for djangorecipe to add a wsgi_initialization parameter which allows
you to put a code block into generated django.wsgi file.

Imported from Launchpad using lp2gh.

• date created: 2009-03-06T13:01:05Z
• owner: hazmat
• the launchpad url was https://bugs.launchpad.net/bugs/338735

generating a wsgi stub on the 0.17 release creates a broken wsgi file.. here's some of the output

configuration

[django]
recipe = djangorecipe
project = wdl
settings = settings
pythonpath =
${buildout:directory}/lib
eggs =
${buildout:eggs}
${lxml:egg}
${mysql:egg}
wdl.ingest
pymarc
solrpy
version = 1.0.2
wsgi = true

wsgi stub bottom half

Set our settings module

os.environ['DJANGO_SETTINGS_MODULE'] = 'wdl.settings'

import datetime
class logger(object):
def init(self, logfile):
self.logfile = logfile

def write(self, data):
    self.log(data)

def writeline(self, data):
    self.log(data)

def log(self, msg):
    line = '%s - %s

' % (
datetime.datetime.now().strftime('%Y%m%d %H:%M:%S'), msg)
fp = open(self.logfile, 'a')
try:
fp.write(line)
finally:
fp.close()
sys.stdout = sys.stderr = logger('')

import django.core.handlers.wsgi

Run WSGI handler for the application

application = django.core.handlers.wsgi.WSGIHandler()

Imported from Launchpad using lp2gh.

• date created: 2009-03-26T03:33:09Z
• owner: hazmat
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/348797

I tried setting the settings option in the Django recipe. This put the value into the bin/django script, but djangorecipe.manage.main does not seem to use the value as expected. It does use it to locate the base directory of the project, but it does not actually use this config file.

ie:
in setup_environ the DJANGO_SETTINGS_MODULE environment variable is set to project_name.settings
then in execute_from_command_line DJANGO_SETTINGS_MODULE is optionally overridden using the --settings command line option
and finally down the line in vim django.conf.init.LazySettings DJANGO_SETTINGS_MODULE is used to load the settings file.

For my installation I added the following lines to ./bin/django, just before the djangorecipe.manage.main line:
sys.argv.append('--settings')
sys.argv.append('product.settings')

I couldn't see how to do this with zc.buildout.easy_install.scripts, otherwise I would have provided a patch.

Imported from Launchpad using lp2gh.

• date created: 2008-06-08T08:16:25Z
• owner: nigel-sim
• assignee: jvloothuis
• the launchpad url was https://bugs.launchpad.net/bugs/238288

wsgi & fcgi script that were created by djangorecipe are not uninstalled (or renamed in case the value of the control-script parameter is renamed).

Imported from Launchpad using lp2gh.

• date created: 2009-02-11T18:18:05Z
• owner: tim-timmolendijk
• assignee: jezdez
• the launchpad url was https://bugs.launchpad.net/bugs/328182