s/-setuptools/-pkg-resources/ dependency : also in upstream EGGs?

[Stefano Zacchiroli]

[ Please Cc:-me on replies directed only to -python,
  I'm not subscribed ]

On Sun, Sep 13, 2009 at 11:16:51AM +0200, Matthias Klose wrote:
> python-pkg-resources is packaged as a separate package; usually only
> the pkg_resources module is needed as a runtime dependency.
> please depend on python-pkg-resources instead of python-setuptools
> for the runtime dependency.
>
> There is a chance that this report is a false positive; in this case
> please just close it.

I've fixed this because in fact it is *not* a false positive: the
package in question does not use at runtime other modules than
pkg_resources. Still, I wonder if the solution is as simple as you
claim.

I presume you are trying to make "less needed" python-setuptools at
runtime. Still, packages like this one (but I presume various others) do
have setuptools in their "requires.txt" and, once python-setuptools gets
removed, will end up having an unsatisfied dependency at the EGG
level. Would then work to load, using the EGG system, those packages or
would that fail due to an unsatisfied dependency over "setuptools"?

As I presume the latter, what is the recommended solution?
Patch upstream egg so that it does not declare a dependency over the
full setuptools (because we know that at build-time it is available)?
Or should we rather create a new EGG just for python-pkg-resources and
patch upstream EGGs to rely on it?

TIA,
Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Piotr Ożarowski-2]

[Stefano Zacchiroli, 2009-09-13]
> [ Please Cc:-me on replies directed only to -python,
>   I'm not subscribed ]
[...]

> I presume you are trying to make "less needed" python-setuptools at
> runtime. Still, packages like this one (but I presume various others) do
> have setuptools in their "requires.txt" and, once python-setuptools gets
> removed, will end up having an unsatisfied dependency at the EGG
> level. Would then work to load, using the EGG system, those packages or
> would that fail due to an unsatisfied dependency over "setuptools"?
>
> As I presume the latter, what is the recommended solution?
> Patch upstream egg so that it does not declare a dependency over the
> full setuptools (because we know that at build-time it is available)?
> Or should we rather create a new EGG just for python-pkg-resources and
> patch upstream EGGs to rely on it?

it's safe to remove requires.txt from binary package (not the whole
Egg-info, it can contain important data, f.e. entry points)

--
-=[     Piotr Ożarowski     ]=-
-=[ http://www.ozarowski.pl ]=-

[Stefano Zacchiroli]

On Mon, Sep 14, 2009 at 02:00:43AM +0200, Piotr Ożarowski wrote:
> it's safe to remove requires.txt from binary package (not the whole
> Egg-info, it can contain important data, f.e. entry points)

Uhm, please expand on "it's safe".

I've seen in the past EGG loading due to unsatisfied dependencies at the
EGG level. So if the requires.txt is there, unless something has
changes, it can induce failures in loading.

Then, with "it is safe", do you mean that if the requires.txt is not
there, dependencies at the EGG level will not be checked? That would be
fine in Debian (given we ensure dependencies at another level), but also
a bit risky since we lose a level of runtime testing.

Otherwise, is there are no risks whatsoever in removing requires.txt, I
believe legacy tools used to build packages should do that.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Piotr Ożarowski-2]

[Stefano Zacchiroli, 2009-09-14]
> On Mon, Sep 14, 2009 at 02:00:43AM +0200, Piotr Ożarowski wrote:
> > it's safe to remove requires.txt from binary package (not the whole
> > Egg-info, it can contain important data, f.e. entry points)
>
> Uhm, please expand on "it's safe".

If you have all the dependencies listed in Depends, requires.txt is not
needed even if upstream is using
 
  pkg_resources.require('PyFooBar >= X.Y')

in the code - it will be satisfied by "python-foo >= X.Y" in Depends
(replace foo with module name PyFooBar is providing).

BTW, you cannot rely on requires.txt anyway (although you should always
check it while packaging new upstream release) - upstreams tend to
ignore this file or bump minimum required versions to the ones they use
at the moment.

> I've seen in the past EGG loading due to unsatisfied dependencies at the
> EGG level. So if the requires.txt is there, unless something has
> changes, it can induce failures in loading.
>
> Then, with "it is safe", do you mean that if the requires.txt is not
> there, dependencies at the EGG level will not be checked? That would be
> fine in Debian (given we ensure dependencies at another level), but also
> a bit risky since we lose a level of runtime testing.

If package is not depending on all needed libraries, it's a serious bug
in the package, IMHO.

> Otherwise, is there are no risks whatsoever in removing requires.txt, I
> believe legacy tools used to build packages should do that.

There's no harm in leaving it the binary package (except wasting few CPU
cycles) unless Egg is changed in Debian, like in this case
(pkg_resources is part of setuptools). You can patch setup.py (which
generates requires.txt) to skip setuptools in requires.txt (hint:
install_requires).

Removing requires.txt in dh_py* is not a good idea IMHO, requires.txt
can actually help maintainers (who are not reading debdiff[1]) to
detect new dependencies while testing package.

[1] /me is giving a hard time to sponsorees who didn't read it before
    sending RFS mail :)
--
-=[     Piotr Ożarowski     ]=-
-=[ http://www.ozarowski.pl ]=-