[PATCH 1 of 2 V2] util: add a way to issue deprecation warning without a UI object

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Apr 13 10:45:54 EDT 2017



On 04/13/2017 02:07 PM, Yuya Nishihara wrote:
> On Thu, 13 Apr 2017 01:14:48 +0200, Pierre-Yves David wrote:
>>
>>
>> On 04/10/2017 04:35 PM, Yuya Nishihara wrote:
>>> On Mon, 10 Apr 2017 15:41:08 +0200, Pierre-Yves David wrote:
>>>> On 04/09/2017 03:08 PM, Yuya Nishihara wrote:
>>>>> On Sat, 8 Apr 2017 11:37:20 +0200, Pierre-Yves David wrote:
>>>>>> On 04/08/2017 10:16 AM, Yuya Nishihara wrote:
>>>>>>> On Fri, 7 Apr 2017 19:03:55 +0200, Pierre-Yves David wrote:
>>>>>>>> On 04/06/2017 05:44 PM, Yuya Nishihara wrote:
>>>>>>>>> On Thu, 6 Apr 2017 16:09:07 +0200, Pierre-Yves David wrote:
>>>>>>>>>>> If dirty hack allowed, I would do something like the following:
>>>>>>>>>>>
>>>>>>>>>>>   # util.py
>>>>>>>>>>>   def _deprecwarn(msg, version):
>>>>>>>>>>>       pass
>>>>>>>>>>>
>>>>>>>>>>>   # somewhere ui is available, maybe in dispatch.py
>>>>>>>>>>>   util._deprecwarn = ui.deprecwarn
>>>>>>>>>>
>>>>>>>>>> That is a diry hack. I would prefer we did not used it.
>>>>>>>>>
>>>>>>>>> Yeah, that is dirty and I don't like it. But I'm okay with it as long as
>>>>>>>>> it is a temporary hack.
>>>>>>>>
>>>>>>>> If you think the dirty hack is worth the potential extra exposure, I'm
>>>>>>>> fine with it.
>>>>>>>>
>>>>>>>> However, I'm confused about your usage of "temporary hack" here. Why are
>>>>>>>> you using temporary?
>>>>>>>
>>>>>>> I suppose the hack will hopefully disappear with the vfs compat layer. I'm not
>>>>>>> sure if a permanent one is necessary.
>>>>>>
>>>>>> I think this kind of needs will appears again in the future. So I would
>>>>>> not flag the solution as temporary. I would have made the function local
>>>>>> to the scmutil module.
>>>>>>
>>>>>> So I would rather have a long terms solution. What do you think?
>>>>>
>>>>> If we need less ad-hoc one, I would add a global flag to enable deprecwarn
>>>>> and set it only by global configuration (i.e. ui, not lui nor repo.ui.)
>>>>
>>>> This seems a bit hacky (I also have some concerns about possible of
>>>> deprecated function being created before the ui is. but I'm not sure
>>>> they are funded).
>>>
>>> IMHO it's as bad as using environment variable. Both are a kind of globals.
>>
>> The global assignment possibly keeps an object alive longer than its due
>> time. So I find it a bit hackier.
>
> That's why I proposed a global boolean flag as an alternative.

ha!, I somehow missed that proposal when reading you. That seems 
interesting. If I get back to this area, I'll investigate possible 
timing issue play with that approach

>
>>>>> And perhaps will remove ui.deprecwarn() in favor of util.deprecwarn().
>>>>
>>>> ui.deprecwarn is much more configurable and manageable that the global
>>>> one (based on Python deprec warning). I do not think we should drop
>>>> `ui.deprecwarc` in favor of the other one.
>>>
>>> It's more configurable, but less easy to use because ui is required.
>>>
>>> Anyway, I don't think it's worth spending time for designing the deprecwarn
>>> feature. I'm okay for any of the ideas in this thread.
>>
>> This the current series is right here and implemented. Are you okay with
>> moving forward with it?
>
> Sure. Can you rebase these on tip? The first patch couldn't apply.

Okay, V4 incoming soon.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list