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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel