Hey folks! I was going through the backlog of issu...
# development
b
Hey folks! I was going through the backlog of issues on Github looking for something to work on, and it seems to me that several issues are completed/solved but not marked as closed (a few examples below). In general, what is the protocol on when to close issues vs when to leave them open? Now that I’ve acquired the power to close issues I want to make sure I don’t overstep my bounds 🙂https://github.com/pantsbuild/pants/issues/19816https://github.com/pantsbuild/pants/issues/19888https://github.com/pantsbuild/pants/issues/19532
c
thanks for looking into these. The first one is tricky, it seems it's an issue when the version of PyRight used by pants is ~incompatible from the one used by VScode there may be issues..? Which means changing the version used by pants may resolve it for this user but break for others, potentially. I'm in favor of bumping the version to latest stable of pyright in the backend, I think to not lag too far behind.. but I'm not familiar with pyright if there are any compatibility concerns etc for doing so?
Josh closed the second one, likely an oversight only.
b
Ah, looks like that was closed 36 minutes ago. Maybe as a response to this post
1
c
The last one seems resolved.. we usually let the OP close their own issues when they're satisified with the outcome, but if left for a reasonably long period of time, we usually close them with a comment inviting the OP to re-open if they feel there are unresolved issues/questions.
(yea, meant "likely an oversight by Josh to not close earlier")
b
For the first issue, happy to bump the version of Pyright plus run against my own repos to check compatibility. I’ll also check against Pyright docs to see if there are any breaking changes between the two versions.
👍 1
I will close the last one, I think it should be fixed for everybody and it’ll only come back if/when we run Pyright in a separate sandbox directory rather than in the workspace in the future.
👍 1