ludovicchabant created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D9135
AFFECTED FILES
.hgignore
doc/Makefile
doc/gendoc.py
doc/templates/cmdheader.txt
ludovicchabant created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D9134
AFFECTED FILES
mercurial/help.py
CHANGE DETAILS
diff --git a/mercurial/help.py
> It might be better to test isinstance(stream, io.RawIOBase). If the stream
> is a RawIOBase, write() should return the number of bytes written.
I'm not super familiar with Python C/native extension code, but it doesn't look
to me like the mod_wsgi.Log type is inheriting from an io base class?
# HG changeset patch
# User Ludovic Chabant
# Date 1601413962 25200
# Tue Sep 29 14:12:42 2020 -0700
# Node ID f8726d166fcaa0d690f6783146172758b2e14deb
# Parent 80bf7b1ada15622ea45b8ecc5647404f5acb2905
hgweb: don't try to wrap mod_wsgi loggers
diff --git a/mercurial/utils/procutil.py b
# HG changeset patch
# User Ludovic Chabant
# Date 1601415526 25200
# Tue Sep 29 14:38:46 2020 -0700
# Node ID 0b78eb21c79f02980e59ae30c6049075534b
# Parent f8726d166fcaa0d690f6783146172758b2e14deb
hgdemandimport: exclude more sqlalchemy modules
We could potentially exclude the entire
We are running into a weird python import error over on hg.sr.ht... see this
callstack:
https://paste.sr.ht/~sircmpwn/2f1855857494e1e4ee71b7dbd9ef4fca6b99be89
The fix is to force-import the offending type before we enable hgdemandimport:
from sqlalchemy.dialects.postgresql.base import
ludovicchabant added a comment.
It does seem brittle to me to override some Python internal method anyway?
Can we get rid of this altogether?
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST ACTION
https://phab.mercurial-scm.org/D8272/new/
REVISION DETAIL
ludovicchabant created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.
REPOSITORY
rHG Mercurial
BRANCH
default
REVISION DETAIL
https://phab.mercurial-scm.org/D8272
AFFECTED FILES
mercurial/archival.py
CHANGE DETAILS
diff --git
>
> Should opts[x], opts.get(x), etc really use bytes? They usually get passed as
> **opts, which means their keys are str, I think.
>
Sounds OK to me -- there's probably a whole bunch of places that might need to
be excluded. It might be worth exploring doing the opposite approach, i.e.
> I'm curious to hear what Ludovic thinks, but I'm doubtful that saves
> other contributors more time than it costs for Ludovic, so it's a net
> negative.
>
> I assume you know that Python 2's end of life is Jan 1 2020, so this
> is getting urgent. I don't know about others, but my team will need
> This patch don't apply anymore :-/ It is also very invasive and will be
> painful for all other contributors.
It might be because I created the patch on top of `stable` instead of some
other head?
To be precise it was applied on top of the 9.0 release since that was the
latest on the stable
> I don't care much about the correctness of the hgloader. It's a temporary
> hack, and Python 3 support is still experimental.
I understand it's experimental but you can expect sourcehut to push somewhat
aggressively on it :)
> > Is the plan to run byteify-strings.py on the mercurial codebase
Thanks for the reply!
> AFAIK, that's by-design thing. What the hgloader does is a bunch
> of weird hacks only valid for our codebase, which we'll eventually
> get rid of.
Then either the design is wrong, or the code is wrong.
First, like I said, depending on *how* you import an extension, it
For those who missed my latest adventures on IRC, I recently discovered that
the hgloader (which patches strings and other py3 things at compile time)
doesn't kick in if you load an extension from a specific file-system location.
This means that:
1) If you `pip install hg-evolve` and add
# HG changeset patch
# User Ludovic Chabant
# Date 1561756040 0
# Fri Jun 28 21:07:20 2019 +
# Branch stable
# Node ID 90daf413dfc7a7e4762e6445f05c52b123c6188f
# Parent 756db65030c64b22836fe236d1db3b95477e3ef7
py3: make setup.py py3 compatible
diff --git a/setup.py b/setup.py
> We definitely want this patch, but we equally want a way to test (not
> just locally) that it keeps working. Maybe we can better coordinate the
> efforts in #hg-evolve.
Will do, thanks!
___
Mercurial-devel mailing list
Should I re-create the patch on the latest evolve stable now? Or will someone
else do it?
I'm asking because py3 support is blocking a few things for sourcehut.
Thanks!
On Sat, May 25, 2019, at 00:05, Ludovic Chabant wrote:
> > Does this make any existing tests for evolve pass
> Does this make any existing tests for evolve pass on py3?
The evolve extension wasn't even loading in py3 before this patch --
mercurial core would reject it for trying to add unicode strings to the
command table.
> Taking other patches first would mean this patch would be hard to
> apply and
# HG changeset patch
# User Ludovic Chabant
# Date 1555683992 0
# Fri Apr 19 14:26:32 2019 +
# Branch stable
# Node ID 6805ebb0f1f6a7f34a74732ee6f6ec14e8824e42
# Parent 3611368a1af3037427eb59635c7dad8dab67c606
py3: properly reject non-encoded strings given to hgweb
diff --git
# HG changeset patch
# User Ludovic Chabant
# Date 1555683918 0
# Fri Apr 19 14:25:18 2019 +
# Branch stable
# Node ID 3611368a1af3037427eb59635c7dad8dab67c606
# Parent 4a8d9ed864754837a185a642170cde24392f9abf
py3: handle meta-path finders that only use pre-python3.4 API
diff --git
> Does find_module() return a spec? We might instead have to skip py3.4
> finders.
Ah you're right, it returns something else. It looks like Python
does this:
try:
find_spec = finder.find_spec
except AttributeError:
loader = finder.find_module(name)
if loader is
> > If we want to be consistent with other things like the hgclient API,
> > maybe we shouldn't be nice and encode the string for the caller, and
> > instead reject anything that's not bytes?
>
> Sounds good to reject unicodes explicitly.
I had sent a v2 of my patch with a better way to encode
>
> Gracefully handling missing find_spec() should be fine. But we should
> use hasattr() or getattr() for that (Mercurial’s linter may insist on
> getattr() because I think we still ban hasattr()) because bare
> “except:” is bad.
Thanks, I sent a v2 of my patches yesterday evening with that
# HG changeset patch
# User Ludovic Chabant
# Date 1555683992 0
# Fri Apr 19 14:26:32 2019 +
# Branch stable
# Node ID eaf4d232055361fd79e5d5299fc76d641be2fb6c
# Parent 8214209f30a56052124b7f530d2a955a2b93b14f
py3: convert unicode paths given for hgweb config
diff --git a/mercurial
# HG changeset patch
# User Ludovic Chabant
# Date 1555683918 0
# Fri Apr 19 14:25:18 2019 +
# Branch stable
# Node ID 8214209f30a56052124b7f530d2a955a2b93b14f
# Parent 4a8d9ed864754837a185a642170cde24392f9abf
py3: handle meta-path finders that only use pre-python3.4 API
diff --git
> We'll probably need to fix the caller to not pass in a unicode. Can
> you copy-paste the traceback?
The caller is my own code. It's basically a custom version of the
hgweb.wsgi file (see
https://www.mercurial-scm.org/repo/hg/file/tip/contrib/hgweb.wsgi).
If we want to be consistent with other
>
> Is there any list of exceptions that are known to be safely
> suppressed? Catching AttributeError, TypeError, etc. seems bad.
>
In my case, it's just a missing method so AttributeError is what's being
raised I think (see
https://github.com/benjaminp/six/blob/master/six.py#L164).
My rationale
# HG changeset patch
# User Ludovic Chabant
# Date 1555683918 0
# Fri Apr 19 14:25:18 2019 +
# Branch stable
# Node ID 96a51193678400abf9d04af65e60a8dccf540cd7
# Parent 4a8d9ed864754837a185a642170cde24392f9abf
py3: protect from exceptions thrown by other meta-path finders
diff --git
# HG changeset patch
# User Ludovic Chabant
# Date 1555683992 0
# Fri Apr 19 14:26:32 2019 +
# Branch stable
# Node ID b1baf28288faf3fd628d5104211e1482e77bdf39
# Parent 96a51193678400abf9d04af65e60a8dccf540cd7
py3: convert unicode paths given for hgweb config
diff --git a/mercurial
> On Feb 18, 2019, at 15:30, Jordi Gutiérrez Hermoso
> wrote:
>
> There's an important dogfooding component here. If we think that the
> hgweb docs are useless, then we should completely get rid of them and
> just point people instead to the new docs you're building.
I don’t believe the two
> > - This would let us see the doc for, say, `hg status` over at
> > https://www.mercurial-scm.org/doc/hg-status.1.html
>
> As we discussed in IRC, that page already exists, but it's hard
> to find:
>
> https://www.mercurial-scm.org/repo/hg/help/status
Ah yes I forgot to mention that. There's
Hi there!
I started playing around with improving the Mercurial docs but before I
work on it more and send some patches, I wanted to get some opinions
about what people would like to see here. Sorry about the length of this
email but there's a lot to do IMHO.
What I have in mind is the following
> > Oh right, that's another thing I wanted to ask -- how would I test that?
> > The only idea I have is to log some verbose message ("tool %s has a
> > graphical interface, launching processes simultaneously") and detect that
> > in test. Is there any better way?
>
> Something like that.
# HG changeset patch
# User Ludovic Chabant
# Date 1549173529 28800
# Sat Feb 02 21:58:49 2019 -0800
# Node ID b8e97fbea8490173387735e72cc424c21d7a1c04
# Parent 3a3b053d0882a33ba7ea667052e445b193ffa4df
extdiff: support tools that can be run simultaneously
diff --git a/hgext/extdiff.py b
> Generally looks good. Can you add some tests?
Oh right, that's another thing I wanted to ask -- how would I test that? The
only idea I have is to log some verbose message ("tool %s has a graphical
interface, launching processes simultaneously") and detect that in test. Is
there any better
One thing I'm not quite sure about this change is how to handle the new "gui"
config flag.
I wanted to use (abuse?) the difference between False and None in order to
figure out if we found the flag in a section or not (and fall back to another
section if not). However, passing None as the
# HG changeset patch
# User Ludovic Chabant
# Date 1549173529 28800
# Sat Feb 02 21:58:49 2019 -0800
# Node ID b08ea934c2d5ac097b171ca74e826e4f9dea86a9
# Parent 3a3b053d0882a33ba7ea667052e445b193ffa4df
extdiff: support tools that can be run simultaneously
diff --git a/hgext/extdiff.py b
# HG changeset patch
# User Ludovic Chabant
# Date 1549173509 28800
# Sat Feb 02 21:58:29 2019 -0800
# Node ID 75d87a5ac4d0d26e02d21df87d2a89ac59c6d535
# Parent b08ea934c2d5ac097b171ca74e826e4f9dea86a9
extdiff: don't run gui programs when in a cli-only environment
diff --git a/hgext
> My idea is basically as follows:
>
> if cmd and opts found in extdiff:
> # it must be a user-defined tool
> look for extdiff.gui.
> elif cmd.diffargs found in diff-tools:
> # perhaps it's a stock tool template defined in [diff-tools] (less
> common)
> look for
> Unused in this version. Removed.
>
> Looks like unrelated change. Also removed.
Indeed, sorry, I didn't correctly split my commit in 2. Thanks for the cleanup!
--
l u d o .
. 8 0 17 80
___
Mercurial-devel mailing list
> Can you split this to a separate patch? It'll need a bit more churn,
> and we wouldn't want to make it a blocker of the --per-file/--confirm
> feature.
I just sent PATCH V4 which should be just that feature alone, where, if
you don't specify --confirm, it launches the external tool one by one.
> I do understand however that it would be easy for users to get in a
> messy situation so I guess I'll add a "--batch" option to "--per-file"
> if that's OK?
Another way to solve this would be to actually default to "--prompt" when
"--per-file" is specified, and require "--no-prompt" if you
> What I pointed out last time was that we shouldn't spawn non-GUI tools
> asynchronously. You can see the problem by the following command on Unix.
>
> $ hg --config extdiff.vimdiff= vimdiff -c. --per-file
Mmmh so for this I figured people would use the "--confirm" flag because, if we
use
# HG changeset patch
# User Ludovic Chabant
# Date 1547180577 28800
# Thu Jan 10 20:22:57 2019 -0800
# Node ID 5686d56d5a2cebaa504383b270e359156352090f
# Parent ef0e2f7224358c32b0f62b13e83e89ba2399c8cf
extdiff: add --per-file and --confirm options
The new options lets the user control how
> I was just speaking about the current implementation (without your patch.)
> Maybe I should say .gui flag isn't checked because the current extdiff never
> spawns more than one processes at a time.
Yeah, and I meant that I don't understand what's the difference between one vs.
multiple
> A separate patch seems fine. To make clear, there's no need to check if the
> tool is console-based or not unless multiple diff processes are spawned
> simultaneously. Currently the .gui flag is tested only by filemerge.py.
So you mean I don't need to modify the previous code path (dir-diff),
Thanks for the comments!
> Maybe need to check the .gui flag of the tool. Otherwise the console
> would be messed up if the tool wasn't a GUI program.
Good point, although the existing extdiff code doesn't seem to be checking
that, no? So should I do that in a separate patch?
> Well, I think
> First, can you break this into a series of a few patches?
As you might have seen, I sent the change split in 2 patches to the mailing
list. I didn't change anything else yet, so we can keep discussing the CLI on
the new patch. Thanks!
--
l u d o .
. 8 0 17 80
# HG changeset patch
# User Ludovic Chabant
# Date 1547180577 28800
# Thu Jan 10 20:22:57 2019 -0800
# Node ID dfda7867497e5609a03727508dc0da2cab3218a3
# Parent ef0e2f7224358c32b0f62b13e83e89ba2399c8cf
extdiff: add --mode option
The new option lets the user control how the external program
# HG changeset patch
# User Ludovic Chabant
# Date 1547180523 28800
# Thu Jan 10 20:22:03 2019 -0800
# Node ID ef0e2f7224358c32b0f62b13e83e89ba2399c8cf
# Parent e546c124217485f54b897d050a9573fc4ab97ab7
extdiff: move external tool command line building into separate function
diff --git
> Sorry for late review. Almost all devs were inactive while holidays.
No worries! Between the holidays and the 4.8.2 release, I figured unsolicited
new features were a low priority.
> First, can you break this into a series of a few patches?
>
>
> After sometime of fighting with windows, here I am looking for suggestions on
> how one can use mercurial on windows smoothly and what are the recommended
> ways. Like shall I use MYSYS, did things will work in cmd.exe?
>
> If anyone can shed some light on their experiences and tips and
# HG changeset patch
# User Ludovic Chabant
# Date 1546539395 28800
# Thu Jan 03 10:16:35 2019 -0800
# Node ID cc964d5d3e3faca1bbbc680732c38cf785754fc2
# Parent 5a2a6ab7bc37af9294b58edfd4d224706940ff19
extdiff: add --mode option
The new option lets the user control how the external program
# HG changeset patch
# User Ludovic Chabant
# Date 1546539214 28800
# Thu Jan 03 10:13:34 2019 -0800
# Node ID 5a2a6ab7bc37af9294b58edfd4d224706940ff19
# Parent 5c68b617ba2463eb6f1372a24b139a376c6bf6bd
help: fix typo
diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
54 matches
Mail list logo
