> I like the idea of 'django.apps', which is kinda more explicit than
> just 'apps'. ;-)
Yeah, though it may be confusing because there is no real
"django.apps" module :-/
What about "django.applications"? Any other objections?
> Following on this thought, maybe we can use version numbers (major,
> minor) to help users
> in identifying which Django version we're tracking.
> I.e:
> - django96.apps : Apps for Django-0.96 release
> - django97.apps : Apps for Django-0.97
> ...and so forth..
>
> The advantage of using version numbers is that it would be easy to
> build reusable apps
> for a specific django version, which could be more stable than trunk..
Versionized reusable apps are definitely a desirable feature! But I
don't like the idea of just using different entrypoints for each
Django release or other dependency. The setuptools _do_ have native
support for complex dependencies [1] via the "install_requires"
keyword. If Django would be distributed by using setuptools (to make
Django detectable by the setuptools), you could declare the dependency
in the setup.py file of the Django app:
install_requires = ['Django>=0.96',]
With that, the setup.py would check for the currently installed Django
version and update it, if necessary. I hope to convince some
developers to reintroduce setuptools to the Django code, since it
doesn't make sense to me to reinvent the wheel while designing a
"Django Apps API" (versioning, dependency tracking, packaging).
Best,
Jannis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
