rapid-flag-11972
10/08/2020, 4:09 PM./pants --version
gives me the version I’m running (1.30.0rc0
). When I run ./pants --print-exception-stacktrace fmt ::
pants tells me if changes were made by black, docformatter and isort as it should. So I know that pants is able to format/lint code. However after this I get the following output:
14:36:33 00:00 [main]
(To run a reporting server: ./pants server)
14:37:04 00:31 [setup]
14:37:04 00:31 [parse]
Executing tasks in goals: bootstrap -> fmt
14:37:04 00:31 [bootstrap]
14:37:04 00:31 [substitute-aliased-targets]
14:37:04 00:31 [jar-dependency-management]
14:37:04 00:31 [complete]
FAILURE
FAILURE: Problem locating a java distribution: Failed to locate a JDK distribution with minimum_version None, maximum_version None
Cleaning up file based variables
00:01
ERROR: Job failed: exit code 1
I have ensured that my custom docker image has java and is working as I am able to do java -version
during the same job. Here is the output when checking if java was installed:
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed mode, sharing)
The project itself is python based but since pants told me it wasn’t able to find a java installation I made a custom image with openjdk-11 installed.
Any help is appreciated, thanks!hundreds-father-404
10/08/2020, 4:15 PM2.0.0b3
, which solely uses the much improved “v2” engine. https://www.pantsbuild.org/docs/installation
Even though it’s a beta, we plan to promote to release candidate shortly, and it generally offers a more polished experience than 1.30.1.
(I’m not sure how far you got with BUILD files, but a major improvement is “dependency inference”, which means you can leave off lots of boilerplate you’d normally need to add)rapid-flag-11972
10/08/2020, 4:24 PMhundreds-father-404
10/08/2020, 4:24 PMbackend_packages.remove = ["pants.backend.jvm"]
rapid-flag-11972
10/08/2020, 4:26 PMorange-beach-75711
10/08/2020, 4:29 PMhundreds-father-404
10/08/2020, 4:31 PM['pants.backend.native', 'pants.backend.codegen.protobuf.java', 'pants.backend.codegen.thrift.java', 'pants.backend.codegen.thrift.python']
in backend_packages.remove
. We had this not-great idea in v1 of activating every backend by default, and it was really difficult for us to deprecatepants_version = "2.0.0rc0"
in pants.toml
.
See https://www.pantsbuild.org/docs/protobuf for instructions on gRPC, and https://www.pantsbuild.org/docs/how-to-upgrade-pants-2-0 for a migration guide. We’re happy to help with the upgraderapid-flag-11972
10/12/2020, 1:51 PMorange-beach-75711
10/13/2020, 8:49 PM2.0.0rc0
from 1.30.0rc0
. I'm hitting a roadblock when I run any pants goals.
• Here is the ldebug output of ./pants fmt ::
- https://pastebin.com/su8tGdWJ
• Here is our pants.toml file - https://pastebin.com/YSvGBUXm
Any thoughts on what we may be getting wrong?hundreds-father-404
10/13/2020, 8:51 PM[python-setup].interpreter_search_paths
so that system Python is not used: https://www.pantsbuild.org/docs/python-interpreter-compatibility#changing-the-interpreter-search-pathinterpreter_search_paths = ["<PYENV>"]
did not fix it, which I’m trying to help him debug. I suspect the <PYENV>
expansion isn’t working properly.
If that doesn’t work, try setting to an explicit path like /Users/eric/.pyenv/versions/3.8.5/bin
(Also if it keeps not working, continuing to send -ldebug
is extremely helpful)orange-beach-75711
10/13/2020, 9:06 PM<PYENV>
, nor setting an explicit path worked.
Here's the latest ldebug output - https://pastebin.com/UseybiSR
Latest pants.toml
- https://pastebin.com/4q1zu6dM
Fyi, this is my python version -
14:05:23 paritosh at Paritoshs-MacBook-Pro-2 in ~/workspaces/phaidra/nabu on feature/pants_upgrade U $ which python
/usr/local/opt/pyenv/shims/python
14:05:24 paritosh at Paritoshs-MacBook-Pro-2 in ~/workspaces/phaidra/nabu on feature/pants_upgrade U $ python --version
Python 3.7.7
hundreds-father-404
10/13/2020, 11:15 PM[python-setup].interpreter_search_paths
is properly being applied. However, Pex is not behaving quite like I’d expect.
This might take us a little time to figure out, but it’s our highest priority to fix - we’ve gone through several iterations the past two months on getting this right, and looks like it’s still Not Quite Right, gr.
One more favor, can you please run the same command with -ldebug
and --pex-verbosity=9
? (Warning it will be a ton of output)orange-beach-75711
10/14/2020, 12:19 AM--pex-verbosity=9
attached.hundreds-father-404
10/14/2020, 12:21 AMrc1
out tomorrow with this fixed one way or another :)[pex].executable_search_paths = ["/path/to/pyenv_interp/bin", "/bin", "/sbin", "/usr/sbin"]
(without /usr/bin
, which has the problematic Python interpreter)orange-beach-75711
10/14/2020, 1:19 AMinterpreter_search_paths = ["/usr/local/opt/pyenv/versions/3.7.7/bin", "/bin", "/sbin", "/usr/sbin"]
- https://pastebin.com/Y2QXRVGyhundreds-father-404
10/14/2020, 1:20 AM[python-setup].interpreter_search_paths
, but [pex].executable_search_paths
orange-beach-75711
10/14/2020, 1:32 AMhundreds-father-404
10/14/2020, 1:35 AM/usr/bin
in order to build themselves
Fingers crossed they don’t, until we can fix [python-setup].interpreter_search_paths
[pex].executable_search_paths
, and set [python-setup].interpreter_search_paths = ["<PYENV>"]