On Tue, 2008-09-16 at 05:06 -0700, mrts wrote: > Both of these arguments are valid, but will not help to resolve the > problem: smooth experience in distributing and using pluggable > applications and some order in the current chaos. > > On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > On Tue, 2008-09-16 at 00:16 -0700, mrts wrote: > > > Let me try to wrap this up: > > > > > * there seems to be a general consensus that amending setuptools to > > > create Django-specific extensions is not required > > > * a separate repository is not required, apps should be published to > > > PyPi Famework :: Django category but a central site that tracks the > > > apps there to further classify, rate and enhance them would be useful > > > (like djangoplugables.com) > > > * app naming and namespace issues should be resolved (should all apps > > > have a django-prefix, the de facto standard? should they live in > > > django.apps namespace?) > > > > As others have pointed out, this isn't necessary and would be bad > > practice. Everybody should feel free to use whatever namespace they like > > to avoid clashes and so that we avoid lowering the quality of the Django > > brand (as soon as somebody installs a few low-quality "packages" and > > they misbehave in any way, it's going to be "Django is a pile of > > rubbish" because it's all coming from the Django namespace). > > Lets not use the `django` namespace then -- `djangoapps`, `djc` (as > django community, mimicking z3c), whatnot. Do you think the > introspection and media arguments are irrelevant? These would provide > practical gain apart from the general feel of coherence I'm trying to > advocate. > > As for coherence: standardized toplevel namespace would help to > discern at a glance which bits of a project are Django-related and > which are not, just by looking at the imports in a .py. Everybody > should feel free to use whatever namespace or namespace hierarchy they > like *under* that namespace. > > As for the brand, the existing practice for naming packaged Django > apps is to use the 'django-' prefix anyway. Should that be discouraged > (which doesn't sound good to me)? > > > > * dependencies should be handled with setuptools facilities > > > > As an option, only. This can't be a requirement, since setuptools will > > often download random stuff from the internet, doesn't support signed > > packages as a rule, doesn't integrate well with existing packaging > > systems such as rpm and apt (which includes the fact that it downloads > > random extra stuff without asking) and doesn't make it easy to validate > > the source code at a later date. In other words, it's insecure by design > > and therefore inappropriate for large system installs. People might be > > happy to use it on their laptops or whatever, but a lot of system > > administrators should rightly feel very nervous about using setuptools. > > apt and rpm don't mix with project-specific packages and versioning > (virtualenv/buildout). It is just not feasible (or even possible if > something is built against django-0.96 and something else against > django-1.0)
Don't tell that to my laptop and some systems I admin which have completely parallel installation of Python 2.4 and everything else I need to do Plone work, all managed by rpms, then. They don't like being told that what they're doing is apparently impossible. :-) Yes, it doesn't work trivially with virtualenv, but so what? It's not part of the use-case of virtualenv and buildout which are targeted at an different audience and use-case. Sandboxed development environments have been in use for years and they work very well when you're developing. They're also not how you deploy things to dozens of machines at once in a very large installation. At that point you use the sandboxed environment to build packages that work with the system they're being installed on and which install in parallel. Not every sandbox environment is designed to do that and that is fine. > to dump everything into the global package space if you > have diverse projects hosted on a single server. > > 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. 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. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
