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

Abierto
  • ¿Algo no está bien?
#925 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 7 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
2.2k
Forks
197
Merge medio
2 d 13 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de python-rope/rope

Todos los issues de python-rope/rope

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.