Project.validate() can't detect content changes served by a custom fscommands

Aperta
  • Qualcosa non va?
#925 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 7 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
devtools

Direzione di ricerca

Start from the reproduction script in the issue, which shows that Project.validate() keeps the cached module after an fscommands read() override changes the content. Read ChangeIndicator, which compares os.path.getmtime() and os.path.getsize(), and the Project.validate() path that uses it. The issue offers two designs (a forced invalidation for one resource, or an optional change-indicator hook on fscommands), so the maintainers need to choose one before a patch. Done means the cached module reflects the overlay text after validate(), with existing fscommands implementations still working.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

A custom fscommands.read() lets an editor or a language server give Rope the contents of unsaved buffers. pylsp-rope's WorkspaceFileCommands does this, and so will rope-language-server. Rope caches parsed modules, though, and Project.validate() decides whether a file changed only from ChangeIndicator, which calls os.path.getmtime() and os.path.getsize() on the real file. An edit to a buffer changes neither, so Rope keeps analysing the old module even after validate().

To Reproduce

import pathlib
import tempfile

from rope.base import fscommands
from rope.base.project import Project


class Overlay(fscommands.FileSystemCommands):
    """Serve unsaved editor buffers, fall back to the disk."""

    def __init__(self):
        self.buffers = {}

    def read(self, path):
        if path in self.buffers:
            return self.buffers[path].encode()
        return super().read(path)


root = pathlib.Path(tempfile.mkdtemp())
(root / "m.py").write_text("def f():\n    return 1\n")
overlay = Overlay()
project = Project(str(root), ropefolder=None, fscommands=overlay)
resource = project.get_resource("m.py")
print(sorted(project.get_pymodule(resource).get_attributes()))

overlay.buffers[resource.real_path] = "def g():\n    return 2\n"
project.validate(resource)
print(sorted(project.get_pymodule(resource).get_attributes()))
print(resource.read())

Output on master (46ebf37), Python 3.13:

['f']
['f']
def g():
    return 2

resource.read() returns the new text, but the cached module still has f and not g. Refactorings then compute offsets against text the user no longer has.

Workarounds today

  • pylsp-rope calls the private project.pycore._invalidate_resource_cache(resource) for every open document on every request.
  • libutils.report_change() does invalidate, but the documentation describes it as the call to make after saving, and with the default automatic_soa=True it also runs static object analysis on every call. That's too slow to run on every keystroke.

Proposal

Either of these would be enough, and neither changes the existing fscommands contract:

  1. A public way to invalidate one resource, for example project.invalidate(resource) or project.validate(resource, force=True). This only needs to notify the resource observers, without the analysis that report_change() adds.
  2. An optional hook, for example fscommands.get_change_indicator(path), which ChangeIndicator uses when the fscommands object provides it, and falls back to os.stat() otherwise. An overlay could then return the buffer version.

The second option is close to part of #911, but kept optional, which matches the concern raised in the review of #911 that new fscommands methods must not break existing implementations such as pylsp-rope's.

Editor information

Lingua principale
Python
Stelle
2.2k
Fork
197
Merge medio
2g 13h
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di python-rope/rope

Tutte le issue di python-rope/rope

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.