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