Re: binary package names
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)
Reply to: