Re: python-parse-type

[Simon McVittie]

On Wed, 17 May 2017 at 11:03:40 +0200, Thomas Goirand wrote:
> On 05/16/2017 02:30 PM, Simon McVittie wrote:
> > PyPI packages correspond to Debian source packages, not binary packages.
> 
> I don't think there ever was a source package name policy, neither in
> Debian nor in this group.

I meant conceptually rather than literally for this one - there is indeed
no hard requirement for source package names (because there does not need
to be a hard requirement, because they are not functionally significant
in the same way binary package names are). As far as I'm aware, there
is a loose common-sense policy that the source package name should either
be what upstream call it, or what upstream call it plus some disambiguation
where required (like the way some Python packages reuse the binary package
name python-foo for software that upstream just calls foo).

S

Re: python-parse-type

[Thomas Goirand]

On 05/16/2017 02:38 PM, Piotr Ożarowski wrote:
> hint: Debian Python Policy §3.3 recommends module name, not
> egg/dist/thecurrentnamefromlatestpep

Who are we to decide that names of packages in Debian should be
different from what upstream decided? That's *very* confusing for our
users. I could have done the same kind of example with egg names and
package names...

# sudo apt-get install python-foo-bar
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package python-foobar
[ ... ]

While the import thing should be easy to find (ie: cat
/var/lib/dpkg/info/python-foo.list once the package is installed), the
egg name vs package name is a *way* more confusing. Besides this, our
priority should be our users, and I am convinced that most aren't python
developers.

Cheers,

Thomas Goirand (zigo)

Re: python-parse-type

[Thomas Goirand]

On 05/16/2017 02:30 PM, Simon McVittie wrote:
> PyPI packages correspond to Debian source packages, not binary packages.

I don't think there ever was a source package name policy, neither in
Debian nor in this group.

> dbus-python (upstream and) on PyPI is the source package dbus-python but
> the binary package python-dbus in Debian, because you have to "import dbus"
> to use it.

That "use the name of the import" policy is unfortunate. IMO it should
be replaced by the egg name instead, to avoid requirements name
substitutions which dh-python is working around in some ugly ways (ie:
with a "maintained by hand" list of pydists-overrides). I wish we could
have a constructive discussion about this here.

Cheers,

Thomas Goirand (zigo)

Re: python-parse-type

[Piotr Ożarowski]

[Barry Warsaw, 2017-05-16]
> Why is that wrong?  Agreed it's perhaps less discoverable in this case, but if
> you were looking for the PyPI enum34 package in Debian, you'd find
> python-enum34 first, and it would make sense.

It must be a pain for all these PyPI users...

  >>> import Foo-Bar
  SyntaxError: invalid syntax
  >>> import FooBar
  ImportError: No module named 'FooBar'
  >>> import foobar
  ImportError: No module named 'foobar'
  >>> import foobar34
  ImpoVtError: No module named 'foobar34'
  
dam it!

  $ pip show -f Foo-Bar | grep .py$ | cut -d / -f 1 | sort -u
  foo

  >>> import foo

ah, that's the one!


hint: Debian Python Policy §3.3 recommends module name, not
egg/dist/thecurrentnamefromlatestpep
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: python-parse-type

[Simon McVittie]

On Tue, 16 May 2017 at 08:00:43 -0400, Barry Warsaw wrote:
> On May 16, 2017, at 11:51 AM, Piotr Ożarowski wrote:
> >packaged as python-enum34 (correct name is python-enum, that's why you
> >didn't find it most probably)
> 
> Why is that wrong?  Agreed it's perhaps less discoverable in this case, but if
> you were looking for the PyPI enum34 package in Debian, you'd find
> python-enum34 first, and it would make sense.

Debian Python policy is that the package that lets you "import foo"
into /usr/bin/python is named python-foo, because names are APIs and
APIs are names.

If you import this backported module with "import enum" then it should
in principle be python-enum.

That policy does break down if there are two libraries with the same name
and different APIs; it looks as though that might have been the case here.
If that's true, then the python-enum34 name is a hack for encoding "should
be called python-enum according to Policy, but is incompatible with a
previous enum module", in much the same way that ABI-transition suffix names
like libpcrecpp0v5 are a hack for encoding "should be called libpcrecpp0
according to Policy, but is incompatible with a previous libpcrecpp.so.0".

PyPI packages correspond to Debian source packages, not binary packages.
dbus-python (upstream and) on PyPI is the source package dbus-python but
the binary package python-dbus in Debian, because you have to "import dbus"
to use it.

S

Re: python-parse-type

[Barry Warsaw]

On May 16, 2017, at 08:10 PM, Brian May wrote:

>python-enum - robust enumerated type support in Python
>python3-enum34 - backport of Python 3.4's enum package

Oh yeah, that too. :)

-Barry

Re: python-parse-type

[Barry Warsaw]

On May 16, 2017, at 11:51 AM, Piotr Ożarowski wrote:

>packaged as python-enum34 (correct name is python-enum, that's why you
>didn't find it most probably)
>
>Barry: ;-P

Why is that wrong?  Agreed it's perhaps less discoverable in this case, but if
you were looking for the PyPI enum34 package in Debian, you'd find
python-enum34 first, and it would make sense.

-Barry

Re: python-parse-type

[Ghislain Vaillant]

On Tue, 2017-05-16 at 12:36 +0200, Piotr Ożarowski wrote:
> [Brian May, 2017-05-16]
> > python-enum - robust enumerated type support in Python
> 
> ah, that's why python-enum34 name was chosen, there's even
> "Breaks: python-enum" - I've missed it because it's no longer in
> unstable

Indeed both (enum and enum34) are different projects. The latter is
officially described as a backport of the enum module introduced since
Python 3.4 to previous versions. That's probably the one you should be
using.

Ghis

Re: python-parse-type

[Lars Kruse]

Hi Brian,


Am Tue, 16 May 2017 20:10:02 +1000
schrieb Brian May :

> python-enum - robust enumerated type support in Python

"python-enum" is based on https://pypi.python.org/pypi/enum while
"python-enum34" is based on https://pypi.python.org/pypi/enum34.
"enum" lacks support for IntEnum (and maybe other details). Thus "enum34" is
probably a good choice.

Cheers,
Lars

Re: python-parse-type

[Piotr Ożarowski]

[Brian May, 2017-05-16]
> python-enum - robust enumerated type support in Python

ah, that's why python-enum34 name was chosen, there's even
"Breaks: python-enum" - I've missed it because it's no longer in
unstable
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: python-parse-type

[Brian May]

Nicolas CANIART  writes:

> But there exists a Python 2.7 backport: the enum34 package (there are
> others but I think this one is the most used and standard). See
> https://pypi.python.org/pypi/enum34/1.1.6

Wondering why I thought otherwise. I tested this by running "python" and
then "import enum". Hmmm. I wonder if I had a Python3 virtualenv active
at the time...

Oh well, thanks for the correction.
-- 
Brian May 

Re: python-parse-type

[Brian May]

Piotr Ożarowski  writes:

> packaged as python-enum34 (correct name is python-enum, that's why you
> didn't find it most probably)

I see the following packages:

python-enum - robust enumerated type support in Python
python3-enum34 - backport of Python 3.4's enum package

The first is wheezy and jessie only, and the later looks like Python3
only.

Oh, I see, there is a python-enum34 package too... Will try that.

Thanks for your help.
-- 
Brian May 

Re: python-parse-type

[Piotr Ożarowski]

[Nicolas CANIART, 2017-05-16]
> https://pypi.python.org/pypi/enum34/1.1.6

packaged as python-enum34 (correct name is python-enum, that's why you
didn't find it most probably)

Barry: ;-P
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: python-parse-type

[Nicolas CANIART]

Hi Brian,

  Enums are a Python 3 feature (3.4 to be precise). No enum in Python 2.x:
https://docs.python.org/2/library/index.html

But there exists a Python 2.7 backport: the enum34 package (there are
others but I think this one is the most used and standard). See
https://pypi.python.org/pypi/enum34/1.1.6

Regards,
Nicolas.

2017-05-16 11:39 GMT+02:00 Brian May <br...@linuxpenguins.xyz>:

> Hello,
>
> Trying to build the python-parse-type package on Sid (source is in git
> for DPMT), required by python-pytest-bdd, I get the following error
> repeated a number of times:
>
> Traceback:
> tests/test_parse_util.py:7: in 
> from .parse_type_test import TestCase, unittest
> tests/parse_type_test.py:3: in 
> from parse_type import TypeBuilder
> parse_type/__init__.py:3: in 
> from parse_type.cardinality import Cardinality
> parse_type/cardinality.py:8: in 
> from enum import Enum
> E   ImportError: No module named enum
>
> Huh? I thought enum is a standed python feature for both versions (2.7
> and 3.5) of python in Sid.
>
> Any ideas?
> --
> Brian May <br...@linuxpenguins.xyz>
> https://linuxpenguins.xyz/brian/
>
>

python-parse-type

[Brian May]

Hello,

Trying to build the python-parse-type package on Sid (source is in git
for DPMT), required by python-pytest-bdd, I get the following error
repeated a number of times:

Traceback:
tests/test_parse_util.py:7: in 
from .parse_type_test import TestCase, unittest
tests/parse_type_test.py:3: in 
from parse_type import TypeBuilder
parse_type/__init__.py:3: in 
from parse_type.cardinality import Cardinality
parse_type/cardinality.py:8: in 
from enum import Enum
E   ImportError: No module named enum

Huh? I thought enum is a standed python feature for both versions (2.7
and 3.5) of python in Sid.

Any ideas?
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/