Gets confused when multiple projects are open

[Kaelten]

When multiple projects are open, behaviors become confused.
I had two projects open:

• A python 3.11 project that was developed against ruff.
• A python 3.10 project that was developed against yapf.

I was migrating the 3.10 project over to ruff and had both projects open. During this, I kep having the ruff extension rewriting code to be 3.11 compatible. This was things like replacing references of datetime.timezone.UTC with datetime.UTC.

Ruff configuration in use between the two projects was near-identiical, one of the few exceptions was the target python version was set to py311 and py310 respectively.

This was driving me crazy. I disabled the extension to confirm that it was the ruff extension. Then it occured to me to try closing the 3.11 project window. After closing the 3.11 project window the bad behavior stopped immediately.

Expected behavior
Project settings from one project shouldn't impact other projects.

Environments (please complete the following information):

• IDE: PyCharm Profession 2023.3.3 Build #PY-233.13763.11
• OS: macOS 14.2.1
• Ruff Version 0.2.1
• Plugin version 0.0.29

[Kaelten]

Note: I've also noticed that sometimes one project detects the ruff executable from another project's .venv folder...

[5j9]

Not sure if this is related or not, but I'm frequently getting the following error from pycharm when I have multiple projects open:

com.intellij.openapi.diagnostic.RuntimeExceptionWithAttachments: Read access is allowed from inside read-action (see Application.runReadAction()); see https://jb.gg/ij-platform-threading for details
Current thread: Thread[ApplicationImpl pooled thread 377,4,main] 1200124793 (EventQueue.isDispatchThread()=false)
SystemEventQueueThread: Thread[AWT-EventQueue-0,6,main] 298472496
	at com.intellij.util.concurrency.ThreadingAssertions.createThreadAccessException(ThreadingAssertions.java:149)
	at com.intellij.util.concurrency.ThreadingAssertions.softAssertReadAccess(ThreadingAssertions.java:107)
	at com.intellij.openapi.application.impl.ApplicationImpl.assertReadAccessAllowed(ApplicationImpl.java:1012)
	at com.intellij.openapi.fileEditor.FileDocumentManager.getDocument(FileDocumentManager.java:60)
	at com.intellij.psi.AbstractFileViewProvider.getDocument(AbstractFileViewProvider.java:170)
	at com.intellij.psi.AbstractFileViewProvider$VirtualFileContent.getText(AbstractFileViewProvider.java:446)
	at com.intellij.psi.AbstractFileViewProvider.getContents(AbstractFileViewProvider.java:151)
	at com.intellij.psi.impl.source.PsiFileImpl.getText(PsiFileImpl.java:307)
	at com.koxudaxi.ruff.SourceFile$text$2.invoke(Ruff.kt:273)
	at com.koxudaxi.ruff.SourceFile$text$2.invoke(Ruff.kt:270)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
	at com.koxudaxi.ruff.SourceFile.getText(Ruff.kt:270)
	at com.koxudaxi.ruff.SourceFile.getAsStdin(Ruff.kt:284)
	at com.koxudaxi.ruff.RuffKt.generateCommandArgs(Ruff.kt:309)
	at com.koxudaxi.ruff.RuffKt.runRuff(Ruff.kt:294)
	at com.koxudaxi.ruff.RuffApplyService$apply$$inlined$runReadActionOnPooledThread$default$1$1.call(Ruff.kt:524)
	at com.intellij.openapi.application.impl.ApplicationImpl$3.call(ApplicationImpl.java:280)
	at com.intellij.util.concurrency.ContextCallable.call(ContextCallable.java:32)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at com.intellij.util.concurrency.ContextRunnable.run(ContextRunnable.java:27)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
	at java.base/java.lang.Thread.run(Thread.java:840)

[marceltschoppch]

I can confirm the same misbehaviour (as documented by @Kaelten ) and the same errors (like @5j9 ) when multiple projects with different ruff settings are open.

[bmrobin]

encountering the same issue. some further details, which seems to be the root cause of the problem:

• in project 1, open your .idea/ruff.xml. note the value of <option name="projectRuffExecutablePath" value="$PROJECT_DIR$/ve/bin/ruff" />
• edit something, attempting to trigger the plugin to run
• in project 2, open .idea/ruff.xml. note that the value will have changed to <option name="projectRuffExecutablePath" value="$PROJECT_DIR$/../project_1_dir/ve/bin/ruff" /> instead of what it should be: <option name="projectRuffExecutablePath" value="$PROJECT_DIR$/ve/bin/ruff" />

you can manually edit each file in each project and the plugin will start working again, but eventually the changes you make to fix it will be overridden again (don't know what action specifically triggers this though).

[ceeeeej]

Observing exactly what @bmrobin has said. As a work around, I'm trying to switch to a globally pipx install ruff / ruff-lsp for now. Then at least I won't have PyCharm telling me the ruff.xml file is changing but I guess then I run the risk of using a different version of ruff locally compared to in CI 🤷.