Re: Inconsistency in source package naming for python modules
On 07/10/2013 10:30 PM, Stuart Prescott wrote:
> Thomas Goirand wrote:
>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>>> There is no policy on this either way, so there's no "mistake".
>>
>> Well, the mistake is precisely to have no rule, IMO.
>
> Rules for packaging things are normally there to solve problems of
> interoperability and to assist QA efforts. Which of these is it going to
> help?
>
>> Never the less, I think we should collectively decide what to do, rather
>> than continuing the mess, with everyone having its own rule.
>
> What mess? If there is a perceived mess, why is that a problem in any case?
> How does it help to make a new rule? Who does it help? What problem does
> this solve? Why is any intellectual energy being spent on this at all?
Oh, I need this pyX package... Let's download it.
# apt-get source pyX
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for pyX
shit, let's try again...
# apt-get source python-X
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for python-X
grr...
# apt-get source X
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]
And then, finally, it's called "migrate" instead of "sqlalchemy-migrate"
like upstream called it... :)
(this never happened to me with python-migrate, though that's a good
example of a IMO badly named source package)
And that's just an example on what can go wrong and be really annoying.
It's even more annoying when you are trying to do a "git svn clone"
which takes forever.
Sure, we can continue and have a "free for all" thing, though knowing
what the others do, and try to do the same so we *at least try* to have
a bit of consistency, can't hurt.
> It looks exceedingly like a rule for the sake of having a rule. It will be
> an exceedingly complicated rule in that it will have to cover python
> modules, python applications and other libraries that offer python bindings
> all separately. It will have to be accompanied an explanation of why so many
> packages don't follow it because they were uploaded prior to the rule
> existing. Basically... unless we are going to force every existing source
> package to change name to comply with this rule there is no point in having
> it (and no-one has advocated renaming source packages as is useless work for
> everyone).
Ok, so let's not use the word "rule" but call it "guide-line", and for
future packages only (I have *never* proposed to change already uploaded
packages). Do you feel more comfortable now? :)
Thomas
Reply to: