pantsbuild / pants

The Pants Build System
https://www.pantsbuild.org
Apache License 2.0
3.32k stars 636 forks source link

File system changes not detected under WSL causing stale test runs #16534

Open mr-smidge opened 2 years ago

mr-smidge commented 2 years ago

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):

$ cd /mnt/c/Users/<MyUser>
$ git clone https://github.com/pantsbuild/example-python.git && cd example-python
$ ./pants test ::
(tests run ok)
$ vim helloworld/greet/greeting_test.py
(edit to make the test break, e.g. change the string "Hola, test!" to "Hola, Pants!")

Expected Output

$ ./pants test ::
(tests fail)

Actual Output

$ ./pants test ::
(tests still run ok, but should fail!)

Mediation

Removing the .pids directory tricks the build into reconsidering:

$ rm -rf .pids/
$ ./pants test ::
(tests fail)

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.

sureshjoshi commented 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
benjyw commented 2 years ago

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.

benjyw commented 2 years ago

The proper fix, of course, is native Windows support.

benjyw commented 2 years ago

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.

jsirois commented 2 years ago

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.