Open mr-smidge opened 2 years ago
Discussed just now in Slack: https://pantsbuild.slack.com/archives/C046T6T9U/p1660743319494179
I've been experimenting with setting up a test project to get a feel for pants, but my updates to files are not getting picked up. For example, my source root pattern is "src/*". if I run pants roots, I see 3 directories I made, A, B, and C. If I add directory D and rerun pants roots, I still only see A, B, and C. I noticed that if I make an adjustment to my pants.toml file, it reinitializes the scheduler and the changes are then picked up. After making an adjustment and rerunning pants roots, I now see A, B, C and D. This is just an example with roots, but the same issue is happening with any changes I make to BUILD files, which is incredibly frustrating. Has anyone else experienced this? I'm currently on Windows 10 and using WSL
Possible workaround was turning off the Pants daemon
[GLOBAL]
pantsd = false
Per that slack thread (which will get lost in 90 days): this is because WSL2 mounts the Windows drives as network filesystems (using 9p of all things), and those don't work with advanced filesystem operations that Pants relies on, such as notification and locking.
So a workaround is to work with a repo that is not under a network drive from WSL2's perspective. E.g., your homedir.
The proper fix, of course, is native Windows support.
Note that we don't recommend turning of the daemon because it will kill performance in typical desktop usage scenarios, and presumably this is a desktop situation.
I've un-assigned myself since, if we do decide to attack Windows support, we'll need Python support 1st which means tackling pantsbuild/pex support for Windows. Once that is shipped, My stack could un-wind to pantsbuild/pants support for Windows. Alternatively, someone else could try to concurrently work on the Pants side of support w/o the Python side shipped yet, but that might run into technical difficulties since Pants uses Pex for plugin bootstrapping. I'll re-assign if actually working on this looks imminent.
When run under WSL2, Pants does not seem to detect changes made on the filesystem, leading to stale/misleading test runs. There are probably other ill effects too.
Steps to Reproduce
The issue can be reproduced using the https://github.com/pantsbuild/example-python repo, which (at the time of writing) uses Pants 2.12.0.
In a WSL2 environment (e.g. Ubuntu 22.04 LTS):
Expected Output
Actual Output
Mediation
Removing the
.pids
directory tricks the build into reconsidering:Impact
I use PyCharm as an IDE, running natively under Windows, using a git repo cloned on a Windows file system, but using a WSL-based Python interpreter. As such, I want to be able to use Pants on a codebase originally from Windows within WSL. This bug makes the experience a little unpleasant.
Related Issues
This is the same issue as #10445, but that issue was closed as it related to Pants 1.x. The issue also happens with Pants 2.x.