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

Yuya Nishihara yuya at tcha.org
Thu Apr 13 08:07:05 EDT 2017


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.

> >>> 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.


More information about the Mercurial-devel mailing list