Setuptools 0.6a8 update to fix SourceForge problems
FYI, SourceForge changed their download pages such that older versions of setuptools can no longer recognize them and follow the links to the "real" download pages. I'm releasing 0.6a8 early in order to address these issues. You can update your setuptools with: easy_install -U setuptools If you have an 'ez_setup' subdirectory in a Subversion-based project, you can use 'svn update ez_setup' to ensure you're requiring the latest version. Unfortunately, there are still outstanding bugs, specifically the "space in python.exe filename" problem, and the issue with creating RPMs from source distributions that use the source-control-driven MANIFEST feature. However, these bugs are also in older versions, so they aren't new to 0.6a8. And 0.6a8 also fixes a lot of previous issues with doing Subversion-based development, so it's a good upgrade to get anyway. Sorry for the inconvenience; the original SourceForge processing code was a user contribution and I didn't really vet it for robustness in the face of SourceForge changes. The new parsing code could still be broken by future SF changes, but it's now less likely.
On 16 Nov 2005 at 14:24, Phillip J. Eby wrote:
these issues. You can update your setuptools with:
easy_install -U setuptools
Except on windows, the easy_install binary is in-use: E:\>easy_install -U setuptools Searching for setuptools Reading http://www.python.org/pypi/setuptools/ Reading http://peak.telecommunity.com/DevCenter/setuptools Best match: setuptools 0.6a8 Downloading http://cheeseshop.python.org/packages/2.4/s/setuptools/setuptools-0.6a8-py2.... Processing setuptools-0.6a8-py2.4.egg creating d:\python24\lib\site-packages\setuptools-0.6a8-py2.4.egg Extracting setuptools-0.6a8-py2.4.egg to d:\python24\lib\site-packages Removing setuptools 0.6a6 from easy-install.pth file Adding setuptools 0.6a8 to easy-install.pth file Installing easy_install-script.py script to d:\python24\Scripts Installing easy_install.exe script to d:\python24\Scripts error: d:\python24\Scripts\easy_install.exe: Permission denied (now copy easy_install .exe and .py to a temp location) E:\>f:\temp\easy_install.exe -U setuptools Searching for setuptools Reading http://www.python.org/pypi/setuptools/ Reading http://peak.telecommunity.com/DevCenter/setuptools Best match: setuptools 0.6a8 Downloading http://cheeseshop.python.org/packages/2.4/s/setuptools/setuptools-0. 6a8-py2.4.egg#md5=799018f2894f14c9f8bcb2b34e69b391 Processing setuptools-0.6a8-py2.4.egg removing 'd:\python24\lib\site-packages\setuptools-0.6a8-py2.4.egg' (and everything under it) creating d:\python24\lib\site-packages\setuptools-0.6a8-py2.4.egg Extracting setuptools-0.6a8-py2.4.egg to d:\python24\lib\site-packages setuptools 0.6a8 is already the active version in easy-install.pth Installing easy_install-script.py script to d:\python24\Scripts Installing easy_install.exe script to d:\python24\Scripts Installed d:\python24\lib\site-packages\setuptools-0.6a8-py2.4.egg Processing dependencies for setuptools -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements
At 03:19 PM 11/16/2005 -0500, Brad Clements wrote:
On 16 Nov 2005 at 14:24, Phillip J. Eby wrote:
these issues. You can update your setuptools with:
easy_install -U setuptools
Except on windows, the easy_install binary is in-use:
Argh. Curse you Windows, and your non-Posix filesystem that won't allow replacing open files! :( Thanks for pointing this out; I'll have to tell people to use ez_setup.py on Windows for upgrades. Alternately, I could try having easy_install detect that an .exe targeted for upgrade is in use, and if the .exe is the same as the one it would have installed, it can ignore it. Hm. On the other hand, it would then mean that it would sometimes work, and sometimes not. The real trouble is that the launcher uses spawnv() to run Python, which means that the original easy_install.exe is technically still in use while Python runs. I have to do that in order to avoid returning to the shell prompt before the Python script runs, which produces weird effects (to say the least). For some reason, an execv() of Python on Windows seems to create an independent process instead of replacing the current process. So, I only use execv() to run GUI (.pyw) scripts on Windows. If somebody with more Windows-fu than me can suggest a way to do a more exec-like exec, that unloads the launcher.exe and runs Python without dropping back to a shell prompt *before* the Python script runs, I could make easy_install safely self-upgrading on Windows.
On 17 Nov 2005 at 13:21, Phillip J. Eby wrote:
If somebody with more Windows-fu than me can suggest a way to do a more exec-like exec, that unloads the launcher.exe and runs Python without dropping back to a shell prompt *before* the Python script runs, I could make easy_install safely self-upgrading on Windows.
No-fu here, sorry. In olden times, I think this kind of stuff was done via .bat files and %if errorlevel, plus creating temp copies of the .exe for subsequent respawn. I don't think it's worth the time, an end-user warning should be enough for this rare occurance (with self-upgrading easy_install) .. oth, I think if the install renames the target file first, then creates the new .exe with the correct name, that will work. I'm not sure if you can delete a renamed .exe that's still in-use. -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements
At 01:52 PM 11/17/2005 -0500, Brad Clements wrote:
oth, I think if the install renames the target file first, then creates the new .exe with the correct name, that will work.
I'm not sure if you can delete a renamed .exe that's still in-use.
Even if you could, the rename isn't going to work on older (non-NT) versions of Windows, and even on newer versions I gather that renaming an in-use .exe is harder than it sounds. Maybe what I need is a way to build an executable that doesn't need to keep its .exe open, or perhaps use a .com launcher instead. :)
participants (2)
-
Brad Clements -
Phillip J. Eby