Hi, Thanks for raising these questions, and giving me the opportunity to debunk some of the things you mentioned.
On 05/17/2017 11:31 AM, Piotr Ożarowski wrote: > [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. There's indeed sometimes some difference between the module name and the egg name. Indeed, upstream is to blame. However, never the less, what upstream has chosen as "package name" is the egg name, not the module name. > Why do you think egg name more important than the module name? Because: - It's what upstream has chosen as "package name" - It's what is used for dependencies, so it's good if Debian was using the same dependency names as upstream. Otherwise, we are adding an unnecessary layer of problems, which we are currently dealing with in a poor (and counter-productive) fashion. > It's used in requires.txt, right, but is this name available in the > traceback? These are orthogonal issues. Anyway, a backtrace isn't useful for a user, and any good Python developer will be able to find out what Debian package is involved (a simple apt-file search is enough...). > 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? Most modules carry an egg name these days. It really isn't the case that it's an exception. And as you mentioned, since the current tooling are generating them, it's going to be even more the case. > Are library package names for end users or developers? At the end, it's going to be used by final users, and "Our priorities are our users [and free software]" as you know. > Which name strategy is more useful? I'm not sure what you're asking for here. > The fact that Openstack uses something else and it's easier for you > doesn't meant it's easier for everyone else. This is absolutely not OpenStack specific. Anyone dealing with a large subset of (modern) Python dependencies will be able to confirm it. Cheers, Thomas Goirand (zigo)