[Distutils] RFC: Updating PEP 345

[Jim Fulton]

On Apr 10, 2009, at 10:40 AM, Tarek Ziadé wrote:

> On Fri, Apr 10, 2009 at 4:33 PM, Jim Fulton <jim at zope.com> wrote:
>>
>> On Apr 10, 2009, at 10:30 AM, Tarek Ziadé wrote:
>>
>>> On Fri, Apr 10, 2009 at 2:30 PM, Jim Fulton <jim at zope.com> wrote:
>>>>
>>>> On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Jim Fulton wrote:
>>>>>>
>>>>>> On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote:
>>>>>> ...
>>>>>>>
>>>>>>> I have backed off on the notion of overloading 'Requires:' /
>>>>>>> 'Provides:'
>>>>>>> / 'Obsoletes:', following Jim's notion of deprecating them in  
>>>>>>> favor of
>>>>>>> new fields.  I named them 'Requires-Dist:', 'Provides-Dist:',  
>>>>>>> and
>>>>>>> 'Obsoletes-Dist'.
>>>>>>>
>>>>>>> "Stock" distutils should probably spell the arguments to
>>>>>>> distutils.core.setup predictably:  'requires_dist',  
>>>>>>> 'provides_dist',
>>>>>>> 'obsoletes_dist'.  setuptools can treat 'install_requires' as an
>>>>>>> undeprecated alias for 'requires_dist'.
>>>>>>
>>>>>>
>>>>>> What is the rational for this?  I'd strongly prefer the  
>>>>>> "requires"
>>>>>> argument name to be compatible with setuptools.  Otherwise, I  
>>>>>> think
>>>>>> we'll introduce needless confusion.
>>>>>
>>>>> I'm aiming for self-consistency within the 'PKG-INFO' field names:
>>>>>
>>>>> - 'Requires'
>>>>> - 'Requires-Python'
>>>>> - 'Requires-External'
>>>>>
>>>>> The 'Obsoletes' and 'Provides' fields also need
>>>>> distutils-project-oriented versions, so picking a suffix ('- 
>>>>> Dist') which
>>>>> matched for them seemed cleanest.
>>>>>
>>>>> Add that to the fact that setuptools has no way (yet) to spell
>>>>> 'provides' or 'obsoletes', and it seemed to me clearer to just  
>>>>> make
>>>>> setuptools current argument an alias for the "consistent"  
>>>>> version to be
>>>>> landed in distutils.
>>>>
>>>>
>>>> I get that. In fact, I already got that. :) I think backward
>>>> compatibility
>>>> with existing wide usage is more important and not incompatible.
>>>
>>> we could also support both spellings for one version, and deprecate
>>> the old name with a warning,
>>
>>
>> Strong: -1.
>>
>> Why change the name? A different name isn't going to be better  
>> enough to be
>> worth the hassle. Deprecation is waaaay overrated as a tool for  
>> reducing the
>> pain of making people change their code or habits.
>
> I don't think it's a good idea to have a different name in PKG-INFO
> and in the arguments to describe
> the same element. we should have the same name everywhere for
> consistency at the end.

Argue with Tres. :) He gave an example where setup argument names and  
meta-data field names were different.

> I don't see anything wrong about adding a simple deprecation warning
> here, It won't happen again
> for quite a while.

We disagree then. Too often people use deprecation as a way to argue  
that a change isn't too painful. Sometimes, change is necessary and  
deprecation helps to manage the change. The change we're talking about  
isn't necessary.

...

> OTHO I'd be fine if the current setuptool name is used in PKG-INFO


Me too. :)

Jim

--
Jim Fulton
Zope Corporation