The distinction is useful in the life cycle context: an "application"
could depend on newer/older "libraries" than the one installed on the
system.
django-admin is an application from this life-cycle point of view.
Django is distributed as an "application" that contains its own library
(the package django): django-admin is upgraded along the django package.
Things would get trickier if some other application would depend on
django the package... so upgrading Django would break another application.
btw did you notice you've used the word application ".. a lot of python
applications on my system .."?
Jeroen Dekkers wrote:
At Fri, 4 Jan 2013 11:43:13 +0000,
Paul Moore wrote:
On 4 January 2013 11:06, Antonio Cavallo<a.cava...@cavallinux.eu> wrote:
And I'm talking about **applications** (eg. some code + some library
depending on an installed python stack) vs **libraries** (code simply
installed along the current python stack).
That's the point, though. In general, distutils installs Python
packages, which are *libraries*, not *applications*.
I've got a lot of python applications on my system and AFAIK those are
all installed by distutils / distribute. They are almost all installed
using the debian packages, but those debian packages are created using
distutils / distribute.
I don't think it's useful to the make the distinction and it is not
easy to make anyway (django also installs the django-admin command, so
it is a library or an application?).
Kind regards,
Jeroen Dekkers
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
