Re: [Distutils] formencode as .egg in Debian ??

["David Arnold" <david@mantara.com>]

-->"Phillip" == Phillip J Eby <pje@telecommunity.com> writes:

(btw Phillip, thanks muchly for your patience with this thread)

  Phillip> If you unpack this as-is, but rename EGG-INFO to
  Phillip> foobar.egg-info (today) or foobar-1.2.egg-info (when I
  Phillip> release 0.6a9 of setuptools), and the whole tree above is in
  Phillip> a directory on sys.path, this egg is good to go.

Ok.

  Phillip> I would like to clarify the phrase "shipped as an egg",
  Phillip> though.  To me, that would mean that the developer is
  Phillip> distributing a binary .egg file, and I'm assuming that Debian
  Phillip> is primarily interested in *source* packages, being a Free
  Phillip> Software distribution.

Debian ships both source packages and binary packages.  It's my
impression (although I could be wrong) that most users use only the
binary packages.

  Phillip> (A binary .egg doesn't have to contain source code at all;
  Phillip> you can specifically build it with the source stripped if you
  Phillip> desire.)

Normal Debian Python (binary) packages include .py files, which are
compiled to both .pyc and .pyo as part of their installation, but C
extensions are shipped as pre-built .so libraries.


  Phillip> While I don't advocate changing all Debian Python packages to
  Phillip> add this metadata, I do suggest it's a practical way to deal
  Phillip> with certain dependency issues.

Assume a developer grabs some setuptools-using Python app, and tries to
run it on a Debian system.  It will look in sys.path for its
dependencies.  If it doesn't find the egg info, as I understand it, the
app will then go out and grab those dependencies via PyPI until it's
able to run.

But, if compatible versions of those dependencies are already installed
as Debian packages *without* egg metadata, will these be ignored?


Even if it was possible for Debian to extend this downloading mechanism
so that it looked for dependencies via apt-get before trying to install
from the raw source or egg or whatever, it would usually be the case
that the user running the newly downloaded Python application would not
have permission to install system packages.

Ultimately, I suppose this isn't a major problem -- if a user (or
developer) runs such an application, they might end up pulling down and
installing a bunch of dependencies in their home directory (that's where
they'd go by default, right?)  But once the app is packaged, both it and
its dependencies will be available for all users, so it'll just be early
adopters who will encounter this.




d