Re: python-parse-type
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
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)
binary package names
[Thomas Goirand, 2017-05-17] > 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? who named the module? We didn't, upstream did. Why do you think egg name more important than the module name? It's used in requires.txt, right, but is this name available in the traceback? If it is (one special case with pkg_resources) - why there are two mechanisms? Which one is universal? How many Python libraries provide Egg name (other than the one generated automatically since few Python interpreter releases) and why so little? Why should we optimise for special cases? Are library package names for end users or developers? Which name strategy is more useful? The fact that Openstack uses something else and it's easier for you doesn't meant it's easier for everyone else. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-parse-type
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
