On Tue, Sep 16, 2008 at 5:23 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> > Fredrik Lundh wrote: > > Karen Tracey wrote: > > > > > >> We've had at least three people run into a problem (#9090) after > >> installing 1.0 over an old level. Now, we do document that before > >> installing you should remove any old level. But I find the results when > >> you don't rather odd. It's not just old files renamed/deleted in the new > >> level that wind up being 'leftover' in the site-packages directory. > >> Rather, some files that exist in both levels, and changed between the > >> two, are not updated by install. So you wind up with a mixture of > >> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd > >> failures. > >> > > > > does that apply to PY files, or is it just that you may have PYC files > > from 0.96.x but PY files from 1.0? (Python only looks at the timestamp > > when deciding whether to recompile a PY file, so if your PYC files for > > 0.96.x were created later than the corresponding 1.0 file, Python will > > pick up the wrong file). > > > > is the installer you're referring to here "setup.py", or something else? > > > > > See ticket #9112 for a purported explanation. > > I do not believe the description/explanation in that ticket is correct. It says the new .py files will be copied but .pyc files will not be created, which is not what I have observed. What I have seen is that new .py files are not copied at all. The tree is left with a mixture of old and new .py files. (And to answer Fredrik's question yes, I'm talking about 'setup.py install'.) It does seem to have been caused by inconsistent file dating during the release process over time. One problematic file is django/utils/dates.py. This file was last modified in SVN on 7/4/2007 at 8:11AM, and that is the date/time on the file when extracted from the 1.0 release tar file. However, going back to the 0.96.2 tarball, the date on its django/utils/dates.py file is 10/29/2007. I'm not sure where that date came from. 0.96.2 was announced on django-announce on 5/14/2008, so it's not when 0.96.2 came out. The actual revision level for the file is [2912], which was checked in on 5/16/06. And there's the problem -- it's an earlier level of the file than what's in 1.0, but it appears based on the date to be more recent. Going back to the 0.96.1 tarball (yes I'm a packrat), the date on its django/utils/dates.py is 10/26/2007, which is the same date as 0.96.1 was announced. So the problem seems to be that some of the older tar files for releases used tar file creation date (or ? since I'm not sure about the 0.96.2 one) for files contained in the release, while 1.0 somehow put last-modified in SVN dates on the files (I didn't know SVN would even do that, actually). Seems it would be safer to use tarfile creation date always. That still leaves potential problems for people doing install-overs. Old files that have been renamed/deleted won't get deleted, and that can cause problems. Even though we say you should first delete old levels, and even if the release process is adjusted to fix up the dates, I think it would be a good idea to refuse to install if an old level is detected. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
