Re: Python Egg Guidelines across distros

[Raphael Hertzog]

Hi,

On Tue, 04 Sep 2007, Toshio Kuratomi wrote:
> I'm revising the Fedora Python Guidelines to make better use of eggs and
> saw an interesting bug report against python-docutils that left me
> wondering how Debian had dealt with some of the decisions that I'm
> having to make.  If we come out with similar conclusions, that will be
> one less difference for end users to have to worry about between
> distros.  If we come to different conclusions, at least we'll know what
> to tell users when they ask why things don't work the way they do in
> that other distro :-)

Thanks for the initiative, it's much appreciated!


We don't have a 100% clear policy, the general rule has been that we
don't provide .egg files but we provided the egg meta-informations
along with the usual modules when upstream uses setuptools by default.
In some cases, when other modules requires an egg for a module which is
not using setuptools by default, we apply a patch to use setuptools.

See http://wiki.debian.org/DebianPythonFAQ

However I noticed lately that egg-info are systematically generated
even with distutils based modules and in fact we have
/usr/lib/python2.4/distutils/command/install_egg_info.py provided by
python2.4. I don't know when the change happened and can't find any
note on python's Changelog... Matthias?

So in practice we always provide egg-info but this change has not been
discussed here. That said I don't see a compelling reason to refuse it.

> 2) We're deciding how we want to make packages when we want to have
> multiple versions of a module.  For instance cherrypy is on release
> 3.0.2 but the TurboGears framework requires a 2.2.x version.  So we need
> to provide both versions to our users.  I've been drafting guidelines
> for doing this using eggs[1]_ but some recent discussions with Phillip
> Eby[2]_, setuptools author are proving there are some difficulties to
> doing this.  Have you guys considered doing anything like this?

Again, no general discussion happened on this topic but the cherrypy
maintainer packaged both versions and made them conflict (i.e. they are
not co-installable). So we report the problem back to the user who wants
to use two version of the product at the same time. :-)

http://packages.debian.org/sid/python-cherrypy
http://packages.debian.org/sid/python-cherrypy3

$ apt-cache show python-cherrypy3 | grep Conflicts
Conflicts: python2.3-cherrypy, python2.4-cherrypy, python-cherrypy

> These are my current goals for multiple versions:
> 1) import MODULE should import whatever the vendor decided should be the
> default.
> 2) requires.txt in a project's egginfo should work to select a specific
> version from the installed eggs.
> 3) In a simple script (without requires.txt),
> should work to select a specific version from the installed eggs.

I think you're more advanced than us on this topic and we didn't not have
any plans to try to use setuptools to achieve this.

The python packaging is already complicated enough that we'd like to avoid
having to resort to such things. And in general, the Debian packagers
don't like Eggs as they replace (badly) the functionnalities of our package
manager. So we avoid promoting them and are not keen to use them to solve
new problems that shouldn't exist in the first place.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python Egg Guidelines across distros

[Toshio Kuratomi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 04 Sep 2007, Toshio Kuratomi wrote:

> Thanks for the initiative, it's much appreciated!
>
Thanks for responding!

> 
> We don't have a 100% clear policy, the general rule has been that we
> don't provide .egg files but we provided the egg meta-informations
> along with the usual modules when upstream uses setuptools by default.
> In some cases, when other modules requires an egg for a module which is
> not using setuptools by default, we apply a patch to use setuptools.
> 
> See http://wiki.debian.org/DebianPythonFAQ
>
Nice.  It looks like your policies are designed to do the same things
ours were before we decided to take on multiple versions.

> However I noticed lately that egg-info are systematically generated
> even with distutils based modules and in fact we have
> /usr/lib/python2.4/distutils/command/install_egg_info.py provided by
> python2.4. I don't know when the change happened and can't find any
> note on python's Changelog... Matthias?
> 
> So in practice we always provide egg-info but this change has not been
> discussed here. That said I don't see a compelling reason to refuse it.
> 
Interesting.  I knew that python 2.5 created egg-info for distutils
packages and just found out that our particular python2.5 has a patch to
disable that.  Keep me in the loop as to why you guys added it to your
python2.4; it'll help me explain the benefits of removing our disabling
patch to our python maintainer.

>> 2) We're deciding how we want to make packages when we want to have
>> multiple versions of a module.  For instance cherrypy is on release
>> 3.0.2 but the TurboGears framework requires a 2.2.x version.  So we need
>> to provide both versions to our users.  I've been drafting guidelines
>> for doing this using eggs[1]_ but some recent discussions with Phillip
>> Eby[2]_, setuptools author are proving there are some difficulties to
>> doing this.  Have you guys considered doing anything like this?
> 
> Again, no general discussion happened on this topic but the cherrypy
> maintainer packaged both versions and made them conflict (i.e. they are
> not co-installable). So we report the problem back to the user who wants
> to use two version of the product at the same time. :-)

In Fedora, there's a movement to stop using Conflicts so we're trying to
figure out if we can use setuptools to manage installing in parallel or
need to come up with something ad hoc.  setuptools almost meets our
needs so I think we'll go down that path for now.

>> These are my current goals for multiple versions:
>> 1) import MODULE should import whatever the vendor decided should be the
>> default.
>> 2) requires.txt in a project's egginfo should work to select a specific
>> version from the installed eggs.
>> 3) In a simple script (without requires.txt),
>> should work to select a specific version from the installed eggs.
> 
> I think you're more advanced than us on this topic and we didn't not have
> any plans to try to use setuptools to achieve this.
> 
> The python packaging is already complicated enough that we'd like to avoid
> having to resort to such things.

Well, you guys are way more advanced in terms of multiple installed
versions of the python interpreter so that gives both of us areas we're
concentrating our efforts on.  (I forsee us having to do some work to
catch up in that area in the next couple years as python2.6, python3.0,
and pypy become options different people want to use on the same system.)

> And in general, the Debian packagers
> don't like Eggs as they replace (badly) the functionnalities of our package
> manager. So we avoid promoting them and are not keen to use them to solve
> new problems that shouldn't exist in the first place.
> 
Oh so true :-)  Python eggs, ruby gems, ... it seems that every language
is inventing a packaging format to make our lives harder these days :-)
 I think eggs have some redeeming characteristics as they allow python
modules to take on the parallel installable nature of unix shared
libraries and they create a usable architecture for creating plugins.
Some days that just frustrates me more, though, as I can't quite get the
portions I want to cleanly separate from the assumptions of the portions
I don't...

Thanks for all the good info!
- -Toshio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG3u4aX6yAic2E7kgRAuW2AKCJl0RlORPmPdwz69EipQGilncHkACfVm4X
MfViOLqwy5lqm3M/FJ12n3I=
=NjqA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python Egg Guidelines across distros

[Josselin Mouette]

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 guys were willing to provide one after getting a bug report
> requesting it.  Is this the general Debian policy?  Package by package?
>  Start providing eggs for everything distutils based?  So far, the
> Fedora position has been that setuptools/eggs provide the equivalent of
> an API and therefore we should let upstream implement it, not do it
> ourselves.  This could change with good arguments.

Currently, we are providing it when there is no other choice. As more
and more mislead upstream developers are using eggs, we sometimes need
them for some dependencies, but currently the de facto policy is not to
generate them unless needed.

BTW I've just learned from your reply that python2.4 in Debian was
patched to create eggs for distutils packages. This change was decided
unilaterally by the python maintainer without being discussed here. I
can understand the rationale for it, but I don't like the idea of
encouraging more upstream developers to use eggs.

> 2) We're deciding how we want to make packages when we want to have
> multiple versions of a module.  For instance cherrypy is on release
> 3.0.2 but the TurboGears framework requires a 2.2.x version.  So we need
> to provide both versions to our users.  I've been drafting guidelines
> for doing this using eggs[1]_ but some recent discussions with Phillip
> Eby[2]_, setuptools author are proving there are some difficulties to
> doing this.  Have you guys considered doing anything like this?

We don't and we won't ship eggs in Debian packages; we were happy enough
to be able to ship .egg-info files instead.

I don't think shipping supporting several versions of a package is a
good thing in a distribution, and this should remain an exception rather
than a rule. For cases like TG/CherryPy, you can imagine several
solutions:
  * a conflict between both, like currently in Debian, this is far
from ideal;
  * shipping version 2.x in a private directory and patching TG to
add it to sys.path;
  * renaming version 2.x to something like cherrypy2;
  * use alternatives like we used to do for pygtk, but this worked
very badly.
Ideally TG should be made compatible with version 3 if this isn't too
complicated.

> These are my current goals for multiple versions:
> 1) import MODULE should import whatever the vendor decided should be the
> default.
> 2) requires.txt in a project's egginfo should work to select a specific
> version from the installed eggs.
> 3) In a simple script (without requires.txt),
> should work to select a specific version from the installed eggs.
> 
> I think #3 is the stumbling block as Phillip is insisting that we need
> to use easy_install to generate script wrappers that make the import
> order work rather than having an API that we can count on working.  I
> have to do some more experimentation based on his last post then ask why
> he thinks that.

I don't think you need listen to anything the setuptools developers say,
as they have close to zero understanding of the packaging issues they
create for us.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Python Egg Guidelines across distros

[Stefano Canepa]

Il giorno ven, 07/09/2007 alle 11.32 +0200, Josselin Mouette ha scritto:
> I don't think you need listen to anything the setuptools developers
> say,
> as they have close to zero understanding of the packaging issues they
> create for us. 

Joss,
do you mean using setuptools upstream is bad for the resulting debian
package? Could you explain why?

Bye
sc

-- 
Stefano Canepa aka sc: [EMAIL PROTECTED]  http://www.stefanocanepa.it
Three great virtues of a programmer: laziness, impatience and hubris.
Le tre grandi virtù di un programmatore: pigrizia, impazienza e
arroganza. (Larry Wall)



signature.asc
Description: Questa è una parte del messaggio	firmata digitalmente

Re: Python Egg Guidelines across distros

[Ben Finney]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> I don't think you need listen to anything the setuptools developers
> say, as they have close to zero understanding of the packaging
> issues they create for us.

For users stuck in the middle, it would be good if there was a clear
statement of exactly what those problems are, that we could refer such
setuptools developers to in order that they gain understanding.

Where would we find such an explanation?

-- 
 \  "Programs must be written for people to read, and only |
  `\ incidentally for machines to execute."  -- Abelson & Sussman, |
_o__)  _Structure and Interpretation of Computer Programs_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python Egg Guidelines across distros

[Josselin Mouette]

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 for developers working on a
certain operating system which doesn't have a decent packaging
infrastructure.

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
these would be good ideas, but well... not our problem.)

What remains, still, is a system that tries to duplicate the
functionality of a packaging system, and fails miserably doing so, by
remaining centered on a single programming language and with zero
correlation to the dpkg database. It allows to ship several versions of
the same package and will select them at runtime - something good for
developers, but a nightmare to support in the long term for users. Even
worse, it is intrusive as it requires adding support for this
functionality in packages that used to not have this crap inside.

Besides the blatant FHS violations, useless complexity and new packaging
problems that this creates, you can easily imagine the problems this
kind of stuff creates - things that happen every time someone tries to
make run-time dependencies independent from the packaging system.

Let's say for example a bug in module foo was fixed in a certain
development version. This bug makes application bar crash, and bar's
developers add a dependency on that development version. The Debian
maintainer of python-foo doesn't want to package a development version,
so he just backports the fix on his package. With distutils, things
would end up here. With setuptools, though, application bar will refuse
to run, as the detected version for module foo is not enough. If bar is
packaged for Debian, the maintainer will have to patch it to remove or
downgrade the egg dependency. If it is not, users will just be screwed.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Python Egg Guidelines across distros

[Toshio Kuratomi]

-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 guys were willing to provide one after getting a bug report
>> requesting it.  Is this the general Debian policy?  Package by package?
>>  Start providing eggs for everything distutils based?  So far, the
>> Fedora position has been that setuptools/eggs provide the equivalent of
>> an API and therefore we should let upstream implement it, not do it
>> ourselves.  This could change with good arguments.
> 
> Currently, we are providing it when there is no other choice. As more
> and more mislead upstream developers are using eggs, we sometimes need
> them for some dependencies, but currently the de facto policy is not to
> generate them unless needed.
> 
Understood.  I'm hoping setuptools is just going through growing pains
and the author will soon start considering its limitations from our POV.
   I'm not holding my breath for that, though.

> BTW I've just learned from your reply that python2.4 in Debian was
> patched to create eggs for distutils packages. This change was decided
> unilaterally by the python maintainer without being discussed here. I
> can understand the rationale for it, but I don't like the idea of
> encouraging more upstream developers to use eggs.
>
Any information on the rationale from you or the python maintainer is
appreciated by me.  In deciding what kind of policy we want to adopt I'm
collecting all the information I can get :-)

>> 2) We're deciding how we want to make packages when we want to have
>> multiple versions of a module.  For instance cherrypy is on release
>> 3.0.2 but the TurboGears framework requires a 2.2.x version.  So we need
>> to provide both versions to our users.  I've been drafting guidelines
>> for doing this using eggs[1]_ but some recent discussions with Phillip
>> Eby[2]_, setuptools author are proving there are some difficulties to
>> doing this.  Have you guys considered doing anything like this?
> 
> We don't and we won't ship eggs in Debian packages; we were happy enough
> to be able to ship .egg-info files instead.
> 
Ah.  Possibly a bit of terminology confusion here.  I use egg to mean a
package which has the egg metadata attached to it.  By default we ship
setuptools files using --single-version-externally managed so that info
is contained inside an egg-info directory.  The Fedora guidelines I'm
working on will sometimes have us ship egg-info and source inside an egg
directory hierarchy so we can parallel install modules.  So far we've
had a de facto standard of never shipping a zipped egg file.  We
probably won't make a firm decision on that until someone explicitly
requests it.

> I don't think shipping supporting several versions of a package is a
> good thing in a distribution, and this should remain an exception rather
> than a rule. For cases like TG/CherryPy, you can imagine several
> solutions:
>   * a conflict between both, like currently in Debian, this is far
> from ideal;
>   * shipping version 2.x in a private directory and patching TG to
> add it to sys.path;
>   * renaming version 2.x to something like cherrypy2;
>   * use alternatives like we used to do for pygtk, but this worked
> very badly.

Yep, we've considered all of those and consider all of them to be pretty
poor.  Using eggs is also pretty poor but has the advantage of being the
method supported by upstream.

OTOH, Debian has a greater history of supporting several versions of a
package than Fedora... just not python packages.  (Look at the python
interpreter itself or any of the multi-versioned libraries).
Conceptually, this has precedent it's just the particulars that are new.

> Ideally TG should be made compatible with version 3 if this isn't too
> complicated.
> 
I know it.  Unfortunately upstream TG itself gave up the effort to port
to cherrypy3 (TG2 will be based on paste instead).  cherrpy really
should have versioned their version 3 release but we're not upstream so
*sigh*.

>> These are my current goals for multiple versions:
>> 1) import MODULE should import whatever the vendor decided should be the
>> default.
>> 2) requires.txt in a project's egginfo should work to select a specific
>> version from the installed eggs.
>> 3) In a simple script (without requires.txt),
>> should work to select a specific version from the installed eggs.
>>
>> I think #3 is the stumbling block as Phillip is insisting that we need
>> to use easy_install to generate script wrappers that make the import
>> order work rather than having an API that we can count on working.  I
>> have to do some more experimentation based on his last post then ask why
>> he thinks that.
> 
> I don't think you need listen to anything the setuptools developers say,
> as th

Re: Python Egg Guidelines across distros

[Ondrej Certik]

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 developers, and not much for
> users. More specifically, it was designed for developers working on a
> certain operating system which doesn't have a decent packaging
> infrastructure.

[]

I am forwarding a relevant opinion from a mayavi2, traits mailinglist
(I am doing the packaging of mayavi2 and traits for Debian).

Ondrej


-- Forwarded message --
From: Gael Varoquaux <[EMAIL PROTECTED]>
Date: Sep 10, 2007 1:23 PM
Subject: Re: [Enthought-dev] why setuptools and eggs are bad
To: [EMAIL PROTECTED]


On Mon, Sep 10, 2007 at 12:26:18PM +0200, Ondrej Certik wrote:
> this debate on debian-python mailinglist could be interesting for you
> (see also all related messages):

> http://people.debian.org/~terpstra/message/20070910.084442.11816b2b.en.html

Interesting. These guys have been stumbling on the same issues than us
for packaging.

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
doing everything itself, and not exposing the info it has to the external
world.

This is bad because the way it is doing things may not fit with a certain
platform's need and existing packaging system. Actually setuptools is
designed with Windows in mind.

Now my work around for packaging ETS has been the coarse-grained source
tarballs: I have a script that inspects the dependencies of an egg,
downloads them (this script was an absolute pain to write, and is
fragile, as setuptools does not expose a proper API for all these things,
and there is a lot of guess work to do). It can be enhanced to build a
partial dependency tree (why the hell is it something that we should do,
setuptools must be doing this, I want this info exposed !). Once the
packages downloaded, the dependency tree built, tarballs can be created
with the relevant info, and I can group the packages, in the case of the
ETS. This script should be enhanced to gather the info to make a real
.deb, and expose the relevant info (package description, version, ...) to
another packaging system.

I also totally strip the Python source from anything relevant to
setuptools, this way I am sure there is not setuptools introduced magic
in them. Setuptools is only a build requirement.

Incidentally, this is somewhat similar to Andrew Straw's stdeb, expect it
focuses on downloading and grouping packages.

If you want to forward this mail to the relevant mailing list
(debian-python, setuptools) go for it. I am happy discussing my
conclusions and providing my hackish script to who ever wants it. I wont
go myself on these lists because I don't like complaining without
providing a solution, and I don't have time to look at the problem more
in details. There is a problem, though, and setuptools guys should be
aware of it and try to address it quickly, elsewhere they will have the
community of packagers more and more angry at them. One of the
conclusions of the debian-python thread Ondrej points to is that upstream
maintainers should be discouraged to use setuptools.

Gaël

___
Enthought-dev mailing list
[EMAIL PROTECTED]
https://mail.enthought.com/mailman/listinfo/enthought-dev

Re: Python Egg Guidelines across distros

[Bernd Zeimetz]

> 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
> these would be good ideas, but well... not our problem.)

I've allready seen logs from our buildds where setuptools tried to
download eggs from the net for various reasons That's clearly
somethin we don't want to have.

My way to get rid of the trouble when packaging a python module is
usually to patch setup.py to get rid of setuptools and use distutils
instead. I'm not the only one who thinks like that, for example the
developers from Zenoss got rid of setuptools completely, as it made more
trouble than anything else.

In my opinion there's no need for more than one tool for setup.py.
Distuils may have bugs, but they can be fixed. The egg and 'I'm better
than your systems package manager' features of seuptools are something
sane people should get rid of - YMMV.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python Egg Guidelines across distros

[Josselin Mouette]

Le lundi 10 septembre 2007 à 11:25 -0700, Toshio Kuratomi a écrit :
> > BTW I've just learned from your reply that python2.4 in Debian was
> > patched to create eggs for distutils packages. This change was decided
> > unilaterally by the python maintainer without being discussed here. I
> > can understand the rationale for it, but I don't like the idea of
> > encouraging more upstream developers to use eggs.
> >
> Any information on the rationale from you or the python maintainer is
> appreciated by me.  In deciding what kind of policy we want to adopt I'm
> collecting all the information I can get :-)

I guess the rationale is simply to save work, avoiding to patch a few
packages for generating eggs, and generating dummy eggs for all packages
that might need one some day.

> OTOH, Debian has a greater history of supporting several versions of a
> package than Fedora... just not python packages.  (Look at the python
> interpreter itself or any of the multi-versioned libraries).
> Conceptually, this has precedent it's just the particulars that are new.

We ship multiple python versions, but one of the goals of being able to
easily install them is to ease transitions in unstable, so that only a
single version ends in a stable release.

BTW if you want such features, you might want to have a look at
python-support. I don't think it would require too much work to port it
to Fedora.

> > Ideally TG should be made compatible with version 3 if this isn't too
> > complicated.
> > 
> I know it.  Unfortunately upstream TG itself gave up the effort to port
> to cherrypy3 (TG2 will be based on paste instead).  cherrpy really
> should have versioned their version 3 release but we're not upstream so
> *sigh*.

Not changing the name while breaking the API doesn't look like a
sensible choice indeed.

> > I don't think you need listen to anything the setuptools developers say,
> > as they have close to zero understanding of the packaging issues they
> > create for us.
> > 
> Heh, I know how you feel but I try to resist giving in to it since we're
> going to be living in a world with setuptools for the foreseeable future
> and we'll all have to learn to communicate and compromise in pursuit of
> our goals.

Dealing with setuptools is one necessary thing to achieve, but I don't
think it requires listening to its developers' advice.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Re: Python Egg Guidelines across distros

[Toshio Kuratomi]

-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
doing everything itself, and not exposing the info it has to the external
world.
[...]
I also totally strip the Python source from anything relevant to
setuptools, this way I am sure there is not setuptools introduced magic
in them. Setuptools is only a build requirement.

==

Very interesting.  I quite agree with you that the setuptools API is
highly deficient.  And my attempt to point out one deficiency was
dismissed as the way things are supposed to be by the author.  I think a
redesign and rewirte of setuptools (or at least, the pkg_resource.py
portion of setuptools) would be a good project for someone.

However, I don't agree that setuptools is only a build requirement.
setuptools makes writing plugins for a package much easier than starting
from scratch.

Also, eggs (as in the egg metadata that comes with the packages; not the
optional pseudo-jar copying zip format) may be duplication but it is not
needless duplication.  Elf shared libraries and packages contain
duplicate information but we don't call for removal of versioning
information from either of those because it's provided by the other.
Package versioning is useful at install time.  Shared library versioning
and egg versioning are useful at runtime.  Unfortunately, the rest of
the setuptools baggage (with easy_install and friends) tends to throw up
a smoke screen around this useful aspect of the format.

- -Toshio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG5g5JX6yAic2E7kgRAueBAJ9CksxJhB/Ck739NrL5cUgIjWbCpQCfV6Yk
QagLuG1kDKo8bmXynlxBpa8=
=KJne
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Python Egg Guidelines across distros

[Gael Varoquaux]

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 Perez spent some time profiling to get some hard
numbers on this, and they are not pretty.

> However, I don't agree that setuptools is only a build requirement.
> setuptools makes writing plugins for a package much easier than starting
> from scratch.

That's a good point. That's what they where design to do, in the
beginning.

> Also, eggs (as in the egg metadata that comes with the packages; not the
> optional pseudo-jar copying zip format) may be duplication but it is not
> needless duplication.  Elf shared libraries and packages contain
> duplicate information but we don't call for removal of versioning
> information from either of those because it's provided by the other.
> Package versioning is useful at install time.  Shared library versioning
> and egg versioning are useful at runtime. 

Yes. To be fair, setuptools are coming in to address a fundamental limit
of Python's import mechanism, and they are a very important project. I
feel pretty bad about bashing them. It is true that if nobody actually
works with Philip Elby (I mean send good patches) to improve them, they
will never work as we need them to work. Sigh ! I just don't have time
for that, I already wonder why I am spending my nights in front of a
computer.

Anyway, it a good project for a talented Python packager and the
community badly needs it to happen.

Gaël


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Python Egg Guidelines across distros

[Josselin Mouette]

Le lundi 10 septembre 2007 à 20:40 -0700, Toshio Kuratomi a écrit :
> Also, eggs (as in the egg metadata that comes with the packages; not the
> optional pseudo-jar copying zip format) may be duplication but it is not
> needless duplication.  Elf shared libraries and packages contain
> duplicate information but we don't call for removal of versioning
> information from either of those because it's provided by the other.
> Package versioning is useful at install time.  Shared library versioning
> and egg versioning are useful at runtime.  

This would be true, if dependencies in setuptools had been designed
correctly. And they could have been if the authors had discussed with
people familiar with dependency issues right from the start.

An ELF binary depends on a list of sonames, and requires a list of
symbols. What a distributor needs is to list the packages providing the
files and to ensure that they provide the required symbols. This is
entirely independent from the implementation he chooses.

With setuptools, a python module requires a list of modules with certain
*versions*. And there is no way to reliably convert this information
into valuable one for the distributor.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée