Opened 10 years ago

Closed 10 years ago

Last modified 6 years ago

#7414 closed (fixed)

OS X 10.5: copies admin templates to incorrect location

Reported by: Christopher Schmidt <crschmidt@…> Owned by: Jacob
Component: Tools Version: master
Severity: Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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

Attachments (1)

setup-data-files-macos-r7732.diff (2.2 KB) - added by Adi J. Sieker 10 years ago.
fix for datafiles being installedin the wrong location

Download all attachments as: .zip

Change History (16)

comment:1 Changed 10 years ago by Karen Tracey <kmtracey@…>

Component: Admin interfaceTools
milestone: 1.0
Triage Stage: UnreviewedAccepted

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, and it is 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).

comment:2 Changed 10 years ago by Adi J. Sieker

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

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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/ -> /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/ -> /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 '' in filenames:
    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.

comment:5 Changed 10 years ago by Adi J. Sieker

Owner: changed from nobody to 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.

Changed 10 years ago by Adi J. Sieker

fix for datafiles being installedin the wrong location

comment:6 Changed 10 years ago by Adi J. Sieker

Has patch: set

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

comment:7 Changed 10 years ago by 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.

comment:8 Changed 10 years ago by 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.

comment:9 Changed 10 years ago by Malcolm Tredinnick

Triage Stage: AcceptedReady for checkin

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.

comment:10 Changed 10 years ago by Jacob

milestone: 1.01.0 alpha
Owner: changed from Adi J. Sieker to Jacob
Status: newassigned

comment:11 Changed 10 years ago by Jacob

Resolution: fixed
Status: assignedclosed

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

comment:12 Changed 9 years ago by onurozkan

milestone: 1.0 alphapost-1.0
Needs tests: set
Patch needs improvement: set
Version: SVN1.0

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 ?

comment:13 Changed 9 years ago by Karen Tracey

milestone: post-1.01.0 alpha
Version: 1.0SVN

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.

comment:14 Changed 9 years ago by Karen Tracey

Needs tests: unset
Patch needs improvement: unset

comment:15 Changed 6 years ago by Jacob

milestone: 1.0 alpha

Milestone 1.0 alpha deleted

Note: See TracTickets for help on using tickets.
Back to Top