Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #9987 > unrolled thread

Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package Ondrej Novy <novy@ondrej.org> - 2017-12-01 12:20 +0100
    Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package Simon McVittie <smcv@debian.org> - 2017-12-01 12:50 +0100

#9987 — Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package

[Multipart message — attachments visible in raw view] — view raw

Hi,

2017-12-01 11:25 GMT+01:00 Simon McVittie <smcv@debian.org>:

> Within Debian, wouldn't this be better achieved by having Python 2 packages
> that require enum34 depend on python-enum34 directly, as they already do?
> python-enum34 could have a Provides on some other name if that helped.
>

I already tried this solution.

I added:
https://anonscm.debian.org/cgit/python-modules/packages/enum34.git/commit/?id=ed2496b8582d939a8ad48769a8b513e916d9df5a

which should handle deps to be automatically added by pybuild, which works.

But when some packages requires enum-compat in setup.py:
https://anonscm.debian.org/cgit/python-modules/packages/python-eventlet.git/tree/setup.py#n16

But even with this change you need to patch upstream code, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881989

Without this patch, setuptools install deps fails (tries to download it
from pypi). Build of eventlet doesn't fail, because it doesn't downloads
requirements from pypi. But other packages which depends on eventlet fails.

The proposed name also isn't really compatible with Debian Python
> policies: you can't `import enum_compat` after installing it.
>

you can't, but enum-compat will be even more confusing. Because
python-enum-compat will contain
'/usr/lib/python2.7/dist-packages/enum_compat-0.0.2.egg-info i think
python-enum-compat is correct.

-- 
Best regards
 Ondřej Nový

Email: novy@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

[toc] | [next] | [standalone]

#9988

On Fri, 01 Dec 2017 at 12:13:26 +0100, Ondrej Novy wrote:
> 2017-12-01 11:25 GMT+01:00 Simon McVittie <[1]smcv@debian.org>:
>     Within Debian, wouldn't this be better achieved by having Python 2 packages
>     that require enum34 depend on python-enum34 directly, as they already do?
> 
> I already tried this solution.

That's unfortunate - the solution you tried first does seem better.

Would it perhaps work to bundle enum_compat's egg-info with
python-enum34? It doesn't seem great to be introducing a whole new
source package just to express a conditional dependency (that will itself
become obsolete when Python 2 does), and it's not as if enum_compat has
any actual code, so hopefully it will never have bugs or new versions.
dpkg-source and gbp can do multi-tarball upstreams these days (yquake2
is one example).

That doesn't work either if a Python 3 package depends on enum_compat,
but it would seem a little absurd to have a python3-enum-compat package,
given that we no longer support any version of Python 3 that doesn't
have enum. (And in the worst case, python3-dev could provide egg-info
for enum_compat, if dependencies on it become widespread.)

I can't help wondering whether it would be a better solution for
upstreams that need enum to depend on
(['enum34'] if sys.version < (3, 4) else []), or on Python 3.4
(either way, short-term it's still a Debian patch, but long-term it's
hopefully upstreamable).

    smcv

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web