From: Austin Glaser Date: Sat, 12 Jun 2021 19:52:49 +0000 (-0700) Subject: Find pyproject from vim relative to current file (#1871) X-Git-Url: https://git.madduck.net/etc/vim.git/commitdiff_plain/4a007a881fa9d7757820657056aa376c05e49e9e?ds=sidebyside;hp=4a007a881fa9d7757820657056aa376c05e49e9e Find pyproject from vim relative to current file (#1871) Commit history before merge: * Find pyproject from vim relative to current file * Merge remote-tracking branch 'upstream/main' into find-pyproject-vim * Finish and fix this patch (thanks Matt Wozniski!) Both the existing code and the proposed code are broken. The vim.eval() call (whether it's vim.eval("@%") or vim.eval("fnamemodify(getcwd(), ':t')) returns a string, and it passes that string to find_pyproject_toml, which expects a sequence of strings, not a single string, and - since a string is a sequence of single character strings - it gets turned into a list of ridiculous paths. I tested with a file called foo.py, and added a print(path_srcs) into find_project_root, which printed out: [ PosixPath('/home/matt/f'), PosixPath('/home/matt/o'), PosixPath('/home/matt/o'), PosixPath('/home/matt'), PosixPath('/home/matt/p'), PosixPath('/home/matt/y') ] This does work for an unnamed buffer, too - we wind up calling black.find_pyproject_toml(("",)), and that winds up prepending the working directory to any relative paths, so "" just gets turned into the current working directory. Note that find_pyproject_toml needs to be passed a 1-tuple, not a list, because it requires something hashable (thanks to functools.lru_cache being used) Co-authored-by: Matt Wozniski * I forgot the CHANGELOG entry ... again * I'm really bad at dealing with merge conflicts sometimes * Be more correct describing search behaviour Co-authored-by: Austin Glaser Co-authored-by: Richard Si <63936253+ichard26@users.noreply.github.com> Co-authored-by: Matt Wozniski ---