#3536 closed (fixed)
setup.py is broken in (at least) r4549 on (at least) Win32
Reported by: | anonymous | Owned by: | Jacob |
---|---|---|---|
Component: | Uncategorized | Version: | dev |
Severity: | Keywords: | ||
Cc: | tsal@… | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
c:\> python setup.py
Traceback (most recent call last):
File "setup.py", line 31, in ?
if sys.argv[1] == 'bdist_wininst':
IndexError: list index out of range
c:\> python setup.py bdist_wininst
[.....]
running install_data
creating build\bdist.win32\wininst\DATA
Traceback (most recent call last):
File "setup.py", line 47, in ?
scripts = django/bin/django-admin.py,
File "C:\devstudio\python2.4\lib\distutils\core.py", line 149, in setup
dist.run_commands()
File "C:\devstudio\python2.4\lib\distutils\dist.py", line 946, in run_commands
self.run_command(cmd)
File "C:\devstudio\python2.4\lib\distutils\dist.py", line 966, in run_command
cmd_obj.run()
File "C:\devstudio\python2.4\lib\distutils\command\bdist_wininst.py", line 152
, in run
install.run()
File "C:\devstudio\python2.4\lib\distutils\command\install.py", line 510, in r
un
self.run_command(cmd_name)
File "C:\devstudio\python2.4\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\devstudio\python2.4\lib\distutils\dist.py", line 966, in run_command
cmd_obj.run()
File "C:\devstudio\python2.4\lib\distutils\command\install_data.py", line 62,
in run
dir = convert_path(f[0])
File "C:\devstudio\python2.4\lib\distutils\util.py", line 89, in convert_path
raise ValueError, "path '%s' cannot be absolute" % pathname
ValueError: path '/PURELIB/django\conf\locale' cannot be absolute
Attachments (1)
Change History (20)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 18 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I realize that I should have split this into two bugs. Unfortunately bdist_wininst still fails with the second error above: "ValueError: path '/PURELIB/django\conf\locale' cannot be absolute". Thanks for patching the first part this fast, though!
comment:4 by , 18 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:5 by , 18 years ago
I'm looking into this currently, and it seems the hack put into place is now breaking things.. Is it possible the bdist_wininst problems have been fixed in the distutils? I'll be testing this today on a Win32 system to see if it works without the hack.
comment:6 by , 18 years ago
My suspicions are confirmed under Python 2.5, but I will be testing this under Python 2.4 in the next few minutes. I removed the lines and will post a patch once I've confirmed it works under 2.4.
comment:7 by , 18 years ago
Needs tests: | set |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Confirmed that removal of the hack works under Python 2.4.4 on Win32, the dist builds, and successfully installs a working version of Django.
I can't seem to attach files, and there really isn't a point in making a unified diff when we know where the code is! :)
Basically, the whole hack can be removed.
For those diff-hungry, here's a patch:
Index: setup.py =================================================================== --- setup.py (revision 4637) +++ setup.py (working copy) @@ -26,12 +26,6 @@ else: data_files.append([dirpath, [os.path.join(dirpath, f) for f in filenames]]) -# Small hack for working with bdist_wininst. -# See http://mail.python.org/pipermail/distutils-sig/2004-August/004134.html -if len(sys.argv) > 1 and sys.argv[1] == 'bdist_wininst': - for file_info in data_files: - file_info[0] = '/PURELIB/%s' % file_info[0] - # Dynamically calculate the version based on django.VERSION. version = "%d.%d-%s" % (__import__('django').VERSION)
follow-up: 11 comment:8 by , 18 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
So I just realized, this may not work on Python 2.3, and unfortunately, I don't have a compiler on the Win32 box. Python 2.3 is no longer available in a binary format, it seems - at least, not that I can find on the python site. So - I can't test this on the latest (2.3.6) on Windows. If someone else could, it will point out any problems, and perhaps we can make the hack specific to version 2.3, if it breaks.
If release dates are an indicator, it's possible this was fixed in the 2.3.6 release of Python. Putting this back to accepted, and leaving the Needs tests marked.
comment:9 by , 18 years ago
Cc: | added |
---|
comment:10 by , 18 years ago
Python 2.3 is available in binary form from activestate.com. It's more or less a vanilla build with additional libraries. http://activestate.com/products/activepython/ . I hope this helps...
follow-up: 12 comment:11 by , 18 years ago
Replying to tsal <tsal@arikel.net>:
Python 2.3 is no longer available in a binary format, it seems - at least, not that I can find on the python site. So - I can't test this on the latest (2.3.6) on Windows. If someone else could, it will point out any problems, and perhaps we can make the hack specific to version 2.3, if it breaks.x
From the release notes of 2.3.6: "This is a source only release. The Windows and Mac binaries of 2.3.5 were built with UCS-2 unicode, and are therefore not vulnerable to the problem outlined in PSF-2006-001. The PCRE fix is for a long-deprecated module (you should use the 're' module instead) and the email fix can be obtained by downloading the standalone version of the email package."
So it appears that the 2.3.5 binary would be good enough.
http://www.python.org/ftp/python/2.3.5/Python-2.3.5.exe
comment:12 by , 18 years ago
Replying to Gary Wilson <gary.wilson@gmail.com>:
So it appears that the 2.3.5 binary would be good enough.
http://www.python.org/ftp/python/2.3.5/Python-2.3.5.exe
Gary,
Thanks, I'll look into it and see if I can get this to break on 2.3!
comment:13 by , 18 years ago
After testing this with 2.3.5, I can say that this appears to work perfectly without the "hack" in place.
I installed 2.3.5, rebuilt the dist using the python 2.3 windows .EXE, and everything worked perfectly.
I tested the django-admin.py and it seemed to generate the proper files, both for startproject and startapp.
Is there any need for supporting older than 2.3?
comment:15 by , 18 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
follow-up: 19 comment:16 by , 18 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
So the real test as to whether this works or not is whether the generated file you get from using the bdist_wininst target in setup.py puts all the Django files under the same directory as the django code (so everything under django/ somewhere). It's not clear from your comments above whether you tested that fact -- that's what this hack is trying to accomplish. Could you please confirm that is the case.
comment:17 by , 18 years ago
Reading the link above the hack in setup.py and the effect that poster was seeing without the hack, I'm fairly convinced that it isn't needed for us. It looks like tsal would not have seen anything work if we still needed that hack with Python 2.3. So I'm going to remove it.
comment:18 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:19 by , 18 years ago
Replying to mtredinnick:
So the real test as to whether this works or not is whether the generated file you get from using the bdist_wininst target in setup.py puts all the Django files under the same directory as the django code (so everything under django/ somewhere). It's not clear from your comments above whether you tested that fact -- that's what this hack is trying to accomplish. Could you please confirm that is the case.
Sorry it took so long to respond, but it looks like you've already committed this in 4912. To answer, albeit late, yes, it puts everything under django, as expected.
It's not really broken, since running setup.py without any arguments is invalid. However, I've fixed it so that it behaves like other setup.py instances and prints the usage message when that error occurs (instead of the traceback).