OS X 10.5: setup.py copies admin templates to incorrect location

[Christopher Schmidt <crschmidt@…>]

I'm pretty sure this is some kind of bug with OS X 10.5. The install puts the libraries in:

byte-compiling /Library/Python/2.5/site-packages/django/contrib/admin/templatetags/__init__.py to __init__.pyc

However, it installs the admin templates to:

copying django/contrib/admin/templates/admin/change_form.html -> /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/templates/admin

So, the templates end up in a different place, so they aren't included when django automatically adds an 'app_dir/templates' directory.

I don't remember this happening under 10.4.

The last comment on #653 appears to be the same issue.

This is with r7612.

[Karen Tracey <kmtracey@…>]

We've been getting reports of problems like this on Mac OS X for a while so it's nice to finally have a concrete description of what is going wrong. Changing the component to Tools because I think that covers setup.py, and it is setup.py that will have to change to fix this. Unfortunately I have zero experience with Macs and none to access to test on, so I have no idea how to fix it. Also set milestone to 1.0 since this needs to be fixed by then (though I think earlier would be better, so as to get wider testing for install before 1.0 is frozen).

[Adi J. Sieker]

#6695 mentions a similar problem and was closed as invalid, with the request to reopen it of someone else encounters it.

[Cai <cai@…>]

Using OSX 10.5 on a Mac Book Pro, clean install, Python 2.5, I've also had this problem. The above work around works. When copying the files over, OSX prompts that the folder 'admin' cannot be modified and requests for authentication. I think this is the same as sudo. Either way, copying the templates and media folders into the admin folder fixes the problems.

[aezell]

I just tried the install on my OS X 10.5 machine and the templates for the admin were copied no where. In this snippet from the install output, you can see that the django/contrib/admin/templates directory is completely skipped.

copying build/lib/django/contrib/admin/models.py -> /Library/Python/2.5/site-packages/django/contrib/admin
creating /Library/Python/2.5/site-packages/django/contrib/admin/templatetags
copying build/lib/django/contrib/admin/templatetags/__init__.py -> /Library/Python/2.5/site-packages/django/contrib/admin/templatetags

I verified that it does exist in the SVN checkout which I just updated. A search of the system seems to indicate that it wasn't copied in the wrong place. It just wasn't copied at all.

This is a slightly different symptom of the problem above, but perhaps the issue comes from the same bit of code. My hunch is that something in this directory walking which builds the list of data_files is going haywire in the templates directory:

for dirpath, dirnames, filenames in os.walk(django_dir):
    # Ignore dirnames that start with '.'
    for i, dirname in enumerate(dirnames):
        if dirname.startswith('.'): del dirnames[i]
    if '__init__.py' in filenames:
        packages.append('.'.join(fullsplit(dirpath)))
    elif filenames:
        data_files.append([dirpath, [os.path.join(dirpath, f) for f in filenames]])

My distutils knowledge is nonexistent, but I did notice that it does some special work for the "darwin" platform in distutils.command.install here:

if sys.platform == "darwin":
    sitepkg = os.path.join(sys.prefix, 'lib', 'python' + sys.version[:3], 'site-packages')
    libpy = os.path.join('/Library/Python', sys.version[:3], 'site-packages')
    if self.install_platlib == sitepkg:
        self.install_platlib = libpy
    if self.install_purelib == sitepkg:
        self.install_purelib = libpy
    if self.install_scripts == os.path.join(sys.prefix, 'bin'):
        self.install_scripts = get_config_var('BINDIR')

Just trying to throw some info out there to see if something jogs someone's brain. This is all with r7772.

[Adi J. Sieker]

I'll see wether I can come up with a fix for this. I'm running 10.5 and 10.4 on a second mac.

[Adi J. Sieker]

fix for datafiles being installedin the wrong location

[Adi J. Sieker]

the attached patch installs the data files in the django source tree. Tested with 10.5 standard Python (2.5) and also works fine with MacPorts Python on 10.5.
I haven't had a chance to test on 10.4 but will try and get around to it this week, if nobody beats me to it. :)

[Karen Tracey <kmtracey@…>]

#7802 was another report of this, though not apparent initially since reporter did not mention OS X. I know this is technically not an alpha item but personally I think it would be great if this install issue could get fixed before alpha. Any chance of that? Getting the fix out there sooner rather than later would get wider exposure and ensure all bases are covered by the fix.

[Adi J. Sieker]

I just checked with a standard Python 2.4.3 on MacOSX 10.4, and the admin templates are under site-packages/django/contrib/admin.

[Malcolm Tredinnick]

I'll commit this when I've done my other "more important than urgent" tasks, unless somebody else gets there first. It looks like it should be harmless on non-Mac platforms, so it shouldn't be a net loss even in the worst case.

[Jacob]

(In [8019]) Fixed #7414: fixed setup.py on OSX 10.5. Thanks, ajs.

[onurozkan]

im using macosx 10.5.2 and im still getting same error. am i doing something wrong or code needs patch ?
im django using 1.0 final. anyone getting same error ?

Using loader django.template.loaders.app_directories.load_template_source:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/templates/base.html (File does not exist)

is this bug still continues ?

[Karen Tracey]

This problem was fixed, and the fix is part of 1.0. You seem to be having a slightly different problem, as base.html generally isn't the template file identified when this error is seen. Please follow up on django-users with details of what you are doing when you encounter the error, including a more complete traceback than just that one line. The ticket tracker is not really the best place for problem diagnosis, very few people are going to see what you post here.

[Jacob]

Milestone 1.0 alpha deleted