setup.py is broken in (at least) r4549 on (at least) Win32

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

(In [4550]) Fixed #3536 -- Fixed setup.py so that it prints a usage message if you accidently invoke it without any arguments.

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!

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.

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.

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)

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.

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

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

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!

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?

patch to remove the bdist_wininst hack

Anyone still alive? :)

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.

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.

(In [4912]) Fixed #3338, #3536, #3796 -- Fixed a bunch of setup and build problems in a portable fashion. That took a *lot* longer to debug than I thought it would, so let's try not to break it.

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.