Malcolm Tredinnick wrote: > On Tue, 2008-09-16 at 05:06 -0700, mrts wrote: > > [...] >> setuptools is a necessary evil for the agile developer who frequently >> tracks updates for the bits he relies upon. Hopefully it will be >> improved (the clamor around it is ever-ongoing), but unless we want to >> do it ourselves, we have to accept the state of things. >> > > Wow. You just said we should entirely ditch security because it isn't > convenient. That's exactly the attitude that has made Microsoft the > laughing stock of the professional IT community for the last 15 years. > > Which, sadly, hasn't affected either their profits or their market dominance. > If my original mail had said "nobody should ever use setup tools" or > anything like that, you reply might be valid. Go back and read it. I > said "optional", not "forbidden". There are multiple audiences here. If > Django ever had a hard dependency on setuptools for using third-party > packages it would make it very difficult for system administrators to > use Django because of the large level of security uncertainty and extra > overhead that comes with using it. So, again, it's fine for people who > want to to use setuptools and virtualenv and buildout and eggs and > rinky-dinky-tool-of-choice. People use things knowing that there are > always trade-offs and compromises. It's bad once policy starts being > enforced on something that is simply unusable in certain environments. > Yes, anyone looking for "the one true way" is doomed to disappointment. You only have to review recent correspondence on python-dev to realize that no one person is aware of all the requirements of the various platforms for which modern applications must be packaged.
I don't much like the pejorative implication of matching "rinky-dinky-tool-of-choice" with the other listed alternative, however. Personally I think virtualenv is a good solution to a tricky problem. The thing that bugs me most of all is Python developers who assume that the answer to all Python distribution problems is the assumption that a single Python installation can support all required applications. In this day and age it's quite practical to look at distributing the required interpreter as a component of your application or framework. There is no reason why your Python program and mine need have any components in common, and increasingly less reason to enforce this requirement to save disk space. Having said which, Django and other frameworks don't have that luxury: if I'm running Django on 2.4 then every app my Django installation supports also has to run on 2.4. regards Steve --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
