Hi,
The reason why I get rid of setuptools as a install and runtime
requirement is that they introduce a huge over head on the import, using
namespace packages. I searched my mailbox all across to find the
discussion about that, but it seems it was done orally rather than on
mail. Anyway, Fernando
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
From: Gael Varoquaux <[EMAIL PROTECTED]>
To sum up, the problem is that setup tools is not designed to interact
with the outside world. It does not provide an api for listing
dependencies, does all kind of magic during the install, and insists for
doi
¡Tengo nueva dirección de correo!Ahora puedes escribirme a: [EMAIL PROTECTED]
- RICHARD OPENE
> The most obnoxious things in setuptools, like automatic downloading of
> dependencies at runtime and shipping everything in egg files that have
> to be all decompressed on-the-fly by any python application being run,
> were deactivated in Debian. (I can't imagine an operating system where
> thes
On 9/10/07, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le vendredi 07 septembre 2007 à 22:53 +0200, Stefano Canepa a écrit :
> > do you mean using setuptools upstream is bad for the resulting debian
> > package? Could you explain why?
>
> Setuptools was designed by developers, for develope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josselin Mouette wrote:
> Le mardi 04 septembre 2007 à 08:28 -0700, Toshio Kuratomi a écrit :
>> 1) Do we want to create eggs where they aren't provided upstream. I see
>> that Debian's python-docutils package doesn't provide eggs in Etch but
>> you g
Le vendredi 07 septembre 2007 à 22:53 +0200, Stefano Canepa a écrit :
> do you mean using setuptools upstream is bad for the resulting debian
> package? Could you explain why?
Setuptools was designed by developers, for developers, and not much for
users. More specifically, it was designed fo
7 matches
Mail list logo
