Hi Alex, On 04/12/2012 10:49 PM, Alex Ogier wrote: > The problem is that not everyone uses package managers. A reasonable > way to track django trunk for example is to periodically pull and run > "setup.py install" which is in most cases approximately idempotent. I > have seen setup.py's that use remove_tree as part of a "clean" command > to allow someone to run "setup.py clean && setup.py install" to obtain > a pristine distribution idempotently, which I think is a good idea. > The alternative is to have everyone remember to "rm -rf" their > site-packages django every time they run setup.py install which is a > bit unsavory in my opinion.
I do agree that asking newer users to go digging in site-packages with "rm -rf" is sub-optimal. I think the first-line answer is to discourage newer users (and anyone, really) from installing Django using "python setup.py install", so they'll never have to. As a second-line answer, I'm open to the idea of "python setup.py clean" as an alternative to manual rm -rf in site-packages, if you can provide a reliable implementation of it as a patch attached to #18115 (and no other core developer vetoes the idea; James Bennett in particular has traditionally been the guardian of Django's setup.py). > The "real" solution to this problem is to stop treating the existence > of files as implicit indication of their inclusion in Django. This is requesting a flat-out impossibility, since "existence of files implies their inclusion" is simply *how Python module imports work*. If a .py file exists somewhere under django/ in a directory with an __init__.py, it can be imported as part of Django. > would mean listing somewhere the files from > django/conf/project_template/ that should be included, which isn't > very DRY, but is the only 100% solution I think. I think this is now the fourth or fifth time it's been pointed out that the problem is not limited to startproject (and you yourself demonstrated that with your own simplejson example!), so I'm a bit mystified how you can still refer to this as a "100% solution." > My recommendation is to make "setup.py clean" do everything possible > to ensure idempotent installation across any version, document that, > and call it a day. Yes, Django can't make up for people who circumvent > their package manager, but we can make it a lot easier to fix than > sending newbies off into their system libraries armed with superuser > permissions and "rm -rf". Agreed. Carl
signature.asc
Description: OpenPGP digital signature