On Thu, Apr 12, 2012 at 11:56 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
>
> Alex Ogier <alex.og...@gmail.com> writes:
>
> > That seems like too much to ask. "setup.py install" should Just
> > Work(tm),
>
> In the absence of a proper package management system (as implemented in
> operating systems that solved this problem decades ago), you can't
> expect it to Just Work. Parallel installation of multiple versions,
> detection of previous versions, upgrade and uninstallation, dependency
> management – these are problems solved by a package manager, and
> ‘setup.py’ doesn't play well with them.
>
> Python's ‘setup.py’ can't be expected to do the job of a package
> manager, especially not in parallel to the OS which often has its own
> package manager.
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.
If someone has managed to get extra files in their site-packages,
because at any point they followed a tutorial on how to build from
source, then their django installation is basically caput until they
manually "rm -rf" a deep library path. One option is to document this
and explain what to do, but this really isn't very discoverable
because telling people that when django is broken, running "sudo rm
-rf" in their python site-packages might fix it is rather akin to
someone calling tech support and them asking, "Well, did you turn off
your computer and turn it on again?" It might fix the problem, but
it's invasive and time-consuming and it shouldn't be necessary.
The "real" solution to this problem is to stop treating the existence
of files as implicit indication of their inclusion in Django. That
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 was bit by this sort of thing a few weeks ago. I had just removed
the simplejson/__init__.py{c,} module and related code and installed a
shim at simplejson.py, all in a feature branch in git. Imagine my
surprise, upon switching to the feature branch several days later, I
found that django was using the old version. The reason was that when
I switched back to the master branch, the simplejson/__init__.pyc was
recompiled and upon checkout out the feature branch git happily
ignored all the .pyc files in my tree. Python saw them and assumed I
had a compiled version of the module and continued using them. So,
that should give you some idea of the perils of not cleaning your
output directories (or in this case, input directory).
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".
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
