Hi Alex, On 04/12/2012 04:23 PM, Alex Ogier wrote: > On Apr 12, 2012 6:16 PM, "Carl Meyer" <c...@oddbird.net > <mailto:c...@oddbird.net>> wrote: >> The correct solution is to warn people away from using installation >> techniques in ways they were not intended to be used, and that don't >> work correctly. Repeated use of "setup.py install" without removing the >> previously-installed version is inherently broken; if we work around one >> specific case where it breaks, there will be others in the future (there >> probably already are). >> > There are ways to support cleaning directories as part of the 'install' > command, for example 'distutils.dir_util.remove_tree'. Adding that for > our specific directory that needs to be clean should work, yes?
The entire django/ subtree should be clean before a new install of Django, not just the new project template. Startproject is not unique, just more visibly problematic. Off the top of my head, a stray file in the built-in management commands directory would also cause an issue - and a stray .py file anywhere would cause imports to continue to work (and bring in outdated code) when they ought to fail for that version of Django. I'm firmly -1 on any workaround that specifically targets the project template; it's just encouraging people to continue to use an installation method that will cause other breakages, perhaps subtler ones. It's possible that Django's setup.py could manually remove the entire django/ directory from the target site-packages, but I don't think that would be a good idea either; it'd be non-standard behavior that would break the expectations of anyone who's used other setup.py files. I still think the right solution is to encourage (via the documentation) installation practices that work reliably, not to try to apply piecemeal workarounds to specific breakages caused by installation practices that don't work reliably (and still won't after the piecemeal workaround). Carl
signature.asc
Description: OpenPGP digital signature
