Inside step2, this is the output I get: ```./pants...
# general
Inside step2, this is the output I get:
Copy code
./pants run main/
18:05:39.93 [ERROR] 1 Exception encountered:

  NoApplicableTargetsException: No files or targets specified. The `run` goal works with these target types:

  * pex_binary
  * python_source
  * python_test

Please specify relevant file and/or target arguments. Run `./pants --filter-target-type=pex_binary,python_source,python_test list ::` to find all applicable targets in your project, or run `./pants --filter-target-type=pex_binary,python_source,python_test filedeps ::` to find all applicable files.
But then when I get it going in step3, and go back to step2, sometimes it will run successfully! Very strange.
I haven't cloned and hacked yet, but one obvious thing (to a Pants user) you have not grappled with yet is teaching Pants your source roots (PYTHONPATH when dealing with Python): Almost nothing should work unless Pants understands that.
Did you try setting those up or otherwise run across that concept yet?
No. But it seems very weird that it doesn't work, then mysteriously starts working.
Agreed, but ... best not to focus on that. I'll take a look at that here shortly. Source roots are ~ step 1
(I had encountered that page but didn't make sense of it, so continued thrashing around).
@rich-kite-32423 how are you running pants? The pants scripts checked in are not marked executable. Do you just clone, mark executable, then never check that modification back in?
This is straight to step2 for me:
Copy code
jsirois@Gill-Windows:~/dev/BruceEckel/ConfiguringForPants/step2 (main) $ chmod +x pants
jsirois@Gill-Windows:~/dev/BruceEckel/ConfiguringForPants/step2 (main *) $ ./pants test ::
17:42:14.66 [INFO] Initializing scheduler...
17:42:14.82 [INFO] Scheduler initialized.
17:42:18.72 [INFO] Canceled: Building pytest.pex from pytest_default.lock
17:42:19.09 [INFO] Completed: Building requirements.pex
17:42:21.09 [INFO] Completed: Building pytest.pex from pytest_default.lock
17:42:21.40 [INFO] Completed: Building local_dists.pex
17:42:22.02 [INFO] Completed: Building pytest_runner.pex
17:42:22.49 [INFO] Completed: Run Pytest - test/ succeeded.
17:42:22.49 [INFO] Completed: Run Pytest - test/ succeeded.
17:42:22.64 [ERROR] Completed: Run Pytest - test/ failed (exit code 2).
============================= test session starts ==============================
platform linux -- Python 3.7.14, pytest-7.0.1, pluggy-1.0.0
rootdir: /tmp/pants-sandbox-Wh2XFV
plugins: forked-1.4.0, cov-3.0.0, xdist-2.5.0
collected 0 items / 1 error

==================================== ERRORS ====================================
______________________ ERROR collecting test/ ______________________
/home/jsirois/.cache/pants/named_caches/pex_root/venvs/s/8feabfd5/venv/lib/python3.7/site-packages/_pytest/ in _importtestmodule
    mod = import_path(self.path, mode=importmode, root=self.config.rootpath)
/home/jsirois/.cache/pants/named_caches/pex_root/venvs/s/8feabfd5/venv/lib/python3.7/site-packages/_pytest/ in import_path
/home/jsirois/.pyenv/versions/3.7.14/lib/python3.7/importlib/ in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1006: in _gcd_import
<frozen importlib._bootstrap>:983: in _find_and_load
<frozen importlib._bootstrap>:967: in _find_and_load_unlocked
<frozen importlib._bootstrap>:677: in _load_unlocked
/home/jsirois/.cache/pants/named_caches/pex_root/venvs/s/8feabfd5/venv/lib/python3.7/site-packages/_pytest/assertion/ in exec_module
    exec(co, module.__dict__)
test/ in <module>
    from main.main import message
E     File "<fstring>", line 1
E       (sys.version = )
E                    ^
E   SyntaxError: invalid syntax
-- generated xml file: /tmp/pants-sandbox-Wh2XFV/ ---
=========================== short test summary info ============================
ERROR test/
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
=============================== 1 error in 0.16s ===============================

✓ test/ succeeded in 0.45s.
✓ test/ succeeded in 0.46s.
✕ test/ failed in 0.60s.
No, I have set them as executable and check in.
Hrm, ok, I clone and pants does not have the executable bit set. That is very strange and alarming.
I see you're running on Linux, not WSL.
I'm on WSL2 Ubuntu 22.04
Windows 11
Another key thing you do not have configured are interpreter constraints. What Python version(s) do you want your code to work with / run under?
I'm on Win 10, if that makes a difference. This is what I get NOW, but wasn't getting when I first created:
Copy code
bruce@groot:/mnt/c/Git/ConfiguringForPants/step2$ ./pants test ::
18:23:15.23 [INFO] Initializing scheduler...
18:23:15.50 [INFO] Scheduler initialized.
18:23:18.79 [INFO] Completed: Run Pytest - test/ succeeded.
18:23:18.79 [INFO] Completed: Run Pytest - test/ succeeded.
18:23:18.79 [INFO] Completed: Run Pytest - test/ succeeded.

✓ test/ succeeded in 0.47s (cached locally).
✓ test/ succeeded in 0.55s (cached locally).
✓ test/ succeeded in 0.54s (cached locally).
which is different than your output.
Key bit is what Python version?
And is that step2?
I'm trying to build it up in little pieces, so I didn't add the interpreter constraints yet. I'm using Python 3.10.6
Ok, that's key though. Really there are ~3 things that must be right from the get go.
Yes, (note the path)
ICs, source roots
I'm missing the path you speak of - help me read tea leaves.
bruce@groot:/mnt/c/Git/ConfiguringForPants/step2$ ./pants test ::
Oh, gotcha!
OK, if those three things must be right, the tutorial is not making that clear.
So, another thing. Not sure if someone mentioned, but you will suffer endlessly trying to use Pants not on the WSL filesystem
You must move your projects off /mnt/c/
OK, that's pretty important
And into the wsl fs or else terror, the fs watching Pants does does not work across plan9fs that Windows uses to netwrok share from C: <-> Linux
I wonder if that didn't cause the delay in having pants work.
Absolutely likely.
Also probably explains weird executable bit thing.
Alright, then I will go back and retry building the tutorial and add the part about moving off /mnt/c/. If that fixes it then that was the issue.
Sounds like a good plan. Also, this fixes for me - aka being explicit about what you expect:
Copy code
jsirois@Gill-Windows:~/dev/BruceEckel/ConfiguringForPants/step2 (main *) $ git diff
diff --git a/step2/pants b/step2/pants
old mode 100644
new mode 100755
diff --git a/step2/pants.toml b/step2/pants.toml
index e1f06c4..ecb26e3 100644
--- a/step2/pants.toml
+++ b/step2/pants.toml
@@ -3,3 +3,6 @@ pants_version = "2.14.0"
 backend_packages = ["pants.backend.python"]
 enabled = false
+interpreter_constraints = ["CPython==3.10.*"]
jsirois@Gill-Windows:~/dev/BruceEckel/ConfiguringForPants/step2 (main *) $ ./pants test ::
17:53:07.39 [INFO] Initializing scheduler...
17:53:07.52 [INFO] Scheduler initialized.
17:53:09.27 [INFO] Canceled: Building pytest.pex from pytest_default.lock
17:53:09.66 [INFO] Completed: Building requirements.pex
17:53:10.78 [INFO] Completed: Building pytest.pex from pytest_default.lock
17:53:11.20 [INFO] Completed: Building local_dists.pex
17:53:11.27 [INFO] Completed: Building requirements.pex with 1 requirement: colored>=1.4.4
17:53:11.87 [INFO] Completed: Building pytest_runner.pex
17:53:11.94 [INFO] Completed: Building pytest_runner.pex
17:53:12.26 [INFO] Completed: Run Pytest - test/ succeeded.
17:53:12.26 [INFO] Completed: Run Pytest - test/ succeeded.
17:53:12.32 [INFO] Completed: Run Pytest - test/ succeeded.

✓ test/ succeeded in 0.38s.
✓ test/ succeeded in 0.38s.
✓ test/ succeeded in 0.38s.
So, I raced it by, but in case you had not heard of all this before, my Christmas Gift: Plan 9 from Outer Space / Rob Pike / not Samba-SMB is how Windows WSL <-> NTFS talk to each other ... and that is a backstory I do not have but would love to know. Absolutely bizarre.
The Pants issue that tracks this is here fwiw:
So it looks like default source roots do work. That would un-nerve me though and I'd personally enumerate explicit ones.
FYI am modifying things and renamed the repo because it seems to be WSL specific now:
@enough-analyst-54434 OK, I've reworked and rewritten everything, including information about the differences between the Windows file system and the WSL file system and why and how to use the latter. I'm still puzzled by the source roots, though. I didn't get much insight or understanding from At the end of the README in
, I suggested adding
Copy code
root_patterns = ["/"]
although I noted that it didn't seem to make any difference.
Also even though I have performed a
chmod +x
on all files that should be executable, this somehow doesn't seem to get uploaded to the git repo.
I'm not sure about the latter - this is certainly a Windowsism of some sort, but I've not run into that issue myself.
In terms of the 1st, you simply need to ensure Pants knows where your PYTHONPATH entries need to be. When a project has its modules and packages at the root, this confuses the issue since a Python interpreter, by default, puts CWD at the head of
, but that aside - Pants just needs to know the list of directories where your module / package roots are. So, for layout:
Copy code
You'd need to tell Pants that `src/`is a source root since your Python code should be importable as
from my_package import a_module
and not
from <|>_package import mymodule
. Confusing things further is that Pants tries to guess the correct source roots and succeeds sometimes! To me, forcing you to be explicit about this would be more clear, but many people like the seeming convenience of the magic working when it does.
@rich-kite-32423 does that make more sense re source roots?
Maybe it helps to imagine a maven-style multi-project repo, but for Python. Then there would be many source roots to define:
Copy code
Or similar.
This same convenient (perhaps) but confusing default magic applies to interpreter constraints. It really, really pays to be explicit about this up front. You surely do not intend your project to work with Python 2.7 for example, good to say that.
I'll have to ponder it more, but it looks like this might be the critical factor: "since your Python code should be importable as
from my_package import a_module
and not
from <|>_package import mymodule
." In my examples I was not using the first form, so maybe if I try that without the source roots it won't work. I'll also look at adding interpreter constraints.
It is definitely true that many people are very confused about source roots, Pants included or not (IDEA has the same concept). So it will be good to feel like you have this nailed.
But its just PYTHONPATH, classpath, etc.; many languages have this idea.
FWIW, it should be the case at the end of the day that there are exactly and only 2 things unique about WSL wrt Pants: 1. Just getting WSL set up. 2. Only using Pants against projects on the WSL filesystem and not under /mnt/<drive>.
The rest of the issues are common to all other OSes.
I'll point out something that adds to the confusion about source roots. The documentation here: which is generally vague and hand-wavy, but also includes: Default source roots The default value of the
config key is
["/", "src", "src/python", "src/py", "src/java", "src/scala", "src/thrift", "src/protos", "src/protobuf"]
. These capture a range of common cases, including a source root at the root of the repository. If your source roots match these patterns, you don't need to explicitly configure them. That's why it works without configuration, and it says "you don't need to explicitly configure them."
Yeah, we're a typical OSS community I guess. Lots of opinions to mediate. I prefer forcing explicit on average. This setup, however, tries to allow you to avoid that.