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

Aberta
  • Algo errado?
#925 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 7 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
30/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Python
Estrelas
2.2k
Forks
197
Merge médio
2d 13h
PRs com merge (30d)
5

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de python-rope/rope

Todas as issues de python-rope/rope

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.