-->"Phillip" == Phillip J Eby <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
