GNU bug report logs - #79036
[PATCH] Fix pdb tracking for remote filenames

Previous Next

Full log

Message #104 received at 79036 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Liu Hui <liuhui1610 <at> gmail.com>,
 michael.albinus <at> gmx.de
Cc: 79036 <at> debbugs.gnu.org
Subject: Re: bug#79036: [PATCH] Fix pdb tracking for remote filenames
Date: Tue, 22 Jul 2025 01:01:26 +0900

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> 
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 23:31:50 +0800
> > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > 
> > On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > > Date: Fri, 18 Jul 2025 22:06:56 +0800
> > > > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > > >
> > > > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > >
> > > > > > file-exists-p: For a local file name in a remote python shell, we
> > > > > > cannot simply distinguish whether it is a file on the remote system or
> > > > > > a local file (i.e. sending code from local host), although the former
> > > > > > is more likely. So we need file-exists-p for verification.
> > > > >
> > > > > Sorry, I don't understand the problem and its solution.  What do you
> > > > > mean by "local file name in a remote python shell"?
> > > >
> > > > For example, below is the pdb output in a remote python shell, and the
> > > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > > ...", we can know the file is on the remote system.
> > > >
> > > >     >>> from test import f; f()
> > > >     > /tmp/test.py(3)f()
> > > >     -> return 1
> > > >     (Pdb)
> > > >
> > > > However, with the following pdb output in a remote python shell
> > > >
> > > >     >>> f()
> > > >     > /tmp/test.py(3)f()
> > > >     -> return 1
> > > >     (Pdb)
> > > >
> > > > The local filename "/tmp/test.py" may be on the remote system like the
> > > > above case, or may be on the local host if we press C-c C-c to send
> > > > its code to the remote process.
> > > >
> > > > Which file should python shell track? The simplest solution is to
> > > > check which file exists.
> > >
> > > Doesn't the value of default-directory tells us whether it's a local
> > > or a remote file?  If not, why not?
> > 
> > In the example:
> > 
> >     >>> f()
> >     > /tmp/test.py(3)f()
> >     -> return 1
> >     (Pdb)
> > 
> > The current buffer is the Python shell buffer, default-directory is
> > remote only means
> >  python process is remote. "/tmp/test.py" may be on the local host because users
> > may send code in local file "/tmp/test.py" to the remote process.
> 
> This cannot work reliably, and I don't think we should support it.
> Please ignore this case in the following discussions.

I agree that this method does not work reliably.  However, I think we
can take another approach.

First, let me explain the problem.  The inferior Python process is
invoked on the remote host if the Python file buffer is remote.  There
are two buffers, both remote.

1. Python file buffer.
2. Inferior Python buffer.

By default, the inferior Python buffer is shared among Python files.
So if we open another local Python file, it uses the above remote
inferior Python buffer.  When we send the contents of the local file
using C-c C-c to the inferior Python buffer, the local file name such
as "/tmp/test.py" is passed.  This results in the above problem.

I think the file name without any prefix such as "/tmp/test.py" should
be used when and only when the inferior Python process can handle it.
When sending the local "/tmp/test.py" to the remote Python process,
passing the file name "/tmp/test.py" is useless because there is no
guarantee that the same "/tmp/test.py" exists on the remote host.
Instead, I think it would be better to pass the file name with the
prefix indicating that the file is local.  The inferior Python process
(PDB) itself still cannot handle that file name, but the PDB tracking
feature can take advantage of it.

If TRAMP supports a method such as "/local:" to access local files, we
can use it.  As TRAMP does not seem to have such a thing, I use
"/ssh::" instead.  The real "/ssh::" requires an SSH server to be
running on the local host, but I'm just using it as a pseudo prefix to
distinguish local files from remote files. i.e. SSH server is not
required on local host.

The case of multiple remote hosts should also be considered.  In
summary, it seems to me that it would be a good idea to pass the file
names as shown in the following table.

|                   | Local Python        | Python on remote1   |
|-------------------+---------------------+---------------------|
| Local tmp.py      | tmp.py              | /ssh::tmp.py        |
| tmp.py on remote1 | /ssh:remote1:tmp.py | tmp.py              |
| tmp.py on remote2 | /ssh:remote2:tmp.py | /ssh:remote2:tmp.py |

Local Python cases are already covered with current python.el.
Attached is a PoC-level patch to support Remote Python cases.

What do you think of this approach?

[79036.diff (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.