I think we largely have a consensus now (unless someone speaks up) -- CheeseShop and the global (or virtualenv) package space is the way to go for all apps when packaging rules have been documented.
If someone wants to take this further, a ticket + a documentation patch that outlines how to package apps would be most welcome. Namespace issues still need to be resolved though. Looks like there should be two topics * "How do I install external packages?" -- outline the two strategies, global and virtualenv (for self-contained project environment), how to find packages etc; * "How should I package and distribute a reusable Django app?" -- what namespace to use, uploading to CheeseShop, registering in djangoplugables (i.e. there should be a semi-official richer environment that lists only Django apps, djangoplugables looks good), dependencies, media etc. On Sep 10, 9:00 pm, "Brett Hoerner" <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 11:20 AM, mrts <[EMAIL PROTECTED]> wrote: > > And it doesn't handle project-local installation (arguably this > > can be done with virtualenv, but that will just clutter user-specific > > "app-space" instead of the global one). > > At some point the Django app you're trying to installed has to go > somewhere. If it doesn't go in global or user's local, where do you > want it to go? Into project dir of course. Most of the existing apps can be trivially installed by cd myproject; wget somewhere/app.tgz; tar zxf app.tgz. > With virtualenv you can (and I would encourage that you) have an env > for each Django project, so any installing you do is only 'cluttering' > that project, and at that point it isn't even 'clutter'. That holds only if you don't live on shared hosting and can afford direct project <-> user (evironment) mapping. If you can't afford that, installing stuff either globally or into virtualenv can create trouble, e.g. project X is written against app Z version 1, project Y is written against (incompatible) version 2 of the same app, both X and Y have to run under the same user (shared hosting) -- the only way to run them is to have a Y-project-local copy of Z. This is a minor, uninteresting problem though, so no need to discuss this further. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
