Hi all! I wondered if toolchain management has been discussed already somewhere. I'm coming at Pants from an existing monorepo which is built using Please, but interested in evaluating Pants as a potential replacement based on its healthier-seeming community and my hopes of a more mature / better documented tool (not that I don't like Please, just that it can be a bit of a trawl to figure out what's going on when it breaks...) One thing we have in our existing Please repo is a good set of rules for managing both Python and Go toolchains, which results in a high degree of hermeticity since everything right down to the language runtime is reproducibly managed by the build tool. I'm aware that Pants uses lockfiles for tools in Python, but not aware of what the (planned) hermeticity mechanisms are for Go, and both are important to us since we're a mixed-language repo. Really my questions here I think are -- what are people's experience with Pants' support for hermetic builds in the absence of toolchain management; are the lockfiles good enough? What does Pants plan for Go support? Is there a philosophical decision not to manage toolchains using the build tool, and if so what are the arguments for / against? Side-note: Please suffers similar Googlability problems to Pants 🙂

@fast-nail-55400 has contributed most of the Go support, so is the best qualified person to tell you about that. :⁠-⁠)

In Resource Hub, there is also a lightning talk by @ancient-vegetable-10556 about Pants' hermeticity model. Hermeticity is provided by core, by the way, not individual backends.

(As an aside, I did a double take on your opening sentence because Pants' corporate sponsor is Toolchain, where I'm in management. Lol.)

Thanks for the quick responses! And yes I'd found Toolchain's site by googling for this same problem!

Need some help. When I try to run a django server using pants, I get a persistent error.

./pants run fleet_backend:manage -- runserver                                                                     ─╯

131030.41 [INFO] Completed: Building local_dists.pex 131043.88 [INFO] Completed: Building fleet_backend/manage.pex with 3 requirements: Django==4.1.7, django-stubs>=1.10.0, python-dotenv Traceback (most recent call last): File "/home/kalungi/projects/fleet-backend/fleet_backend/manage.py", line 10, in main from django.core.management import execute_from_command_line ModuleNotFoundError: No module named 'django' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/home/kalungi/projects/fleet-backend/fleet_backend/manage.py", line 21, in <module> main() File "/home/kalungi/projects/fleet-backend/fleet_backend/manage.py", line 12, in main raise ImportError( ImportError: Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment?

I'm using the same Docker base image, "python:3.10.10-slim-bullseye@.sha256:...", in several different

BUILD

files. Is there a way to define this base image in only one place and reuse it across all my

BUILD

files? I've considered using environmental variables, but I'm not sure if that's the best approach. Does anyone have any suggestions on how to achieve this?

Hi! and welcome @nice-park-16693 👋 you’ll also be happy to learn that the upcoming 2.16.0a0 release will include support for providing a managed Python also for user code https://github.com/pantsbuild/pants/pull/18352 ! 😄 provided by @bitter-ability-32190 🙌

Super cool, thanks for the context @curved-television-6568!

If you want to test it out, let me know! Id love for it to see some air time before the "big release"

So I can also speak to the experience of non-hermetic Python builds. It usually is OK. I manage an org of maybe 100 engineers/data scientists and only get hit by non-hermetic issues maybe once a month? And that's considering these folks don't know the nuances of the Python ecosystem and love running

pip install

(I blame Python, not people). That being said, it's really frustrating to use non-hermetic Python. That's why I'm divorcing Pants from system Python 🙂 The linked PR makes it so you can opt-into having Pants use

pyenv

to build and install Python in a read-only cache directory. So it should become way more hermetic. It'll still rely on system libraries, but nothing is truly hermetic and this is a great improvement.

I am trying to run pants on bitbucket-pipelines. When I run "pants lint package ::", it manages to build all the binaries (pex), but fails to build the docker images, giving me the error`Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?` . In the same script I however can build a normal Dockerfile with

docker build -t hello_docker .

. Any ideas why this might be happening?

@nice-park-16693: What did you want to know specifically about the Go support?

Can a Pants Slack admin contact me (DM) please?

The Go backend currently only supports searching for Go on the system because of performance issues in earlier versions of the Go support due to having to unpack the Go SDK too much. Having Pants manage a Go SDK installation is something we would like to do again, but I'm not aware of engineering resources available at the moment to bring that support back.

@fast-nail-55400 was that before or after we fixed the same problem in Java-land?

well before the "immutable input" work on

Process

and the newer work superseding immutable inputs to symlink inputs instead

as in, the SDK download support existed only before the Go backend was ever released. it released with just searching the local system.

With that in mind: there’s a fairly clear path forward on how to manage the go SDK in a way that is Pants-efficient, which we can probably help someone towards implementing. It’s just not a priority for us to do the heavy lifting ourselves

Yeah we just got this for Python. Opt-in "Pants-provides-it" with the default of "Pants goes looking"

With that in mind: there’s a fairly clear path forward on how to manage the go SDK in a way that is Pants-efficient, which we can probably help someone towards implementing. It’s just not a priority for us to do the heavy lifting ourselves

I have done some initial thinking here. I wanted the Go backend to just have an equivalent to what

pyenv

,

coursier

, and

asdf

do and download and install the Go SDK into a Pants-managed directory.

rather than manage it as a tool that is symlinked into the execution sandbox

Hi all, I'm trying to migrate to Pants but I've hit a bit of a problem. We have a dependency in our stack that we can't pin the version of (yet). I tried various things and then came across Docker Environments in 2.15. Unfortunately I'm getting the following error on

pants test ::

20:23:27.94 [ERROR] 1 Exception encountered:

Engine traceback:
  in `test` goal
  in Run Pytest - (environment:local_docker, tests/test_config_test.py)

Exception: Failed to obtain version from local Docker: error trying to connect: Permission denied (os error 13)

I am able to run all docker commands without

sudo

pants.toml:

[environments-preview.names]
local_docker = "//:local_docker"

[docker]
env_vars = [
  "DOCKER_HOST"
]

BUILD:

__defaults__(all=dict(environment="local_docker"))

docker_environment(
  name="local_docker",
  platform="linux_x86_64",
  image="ubuntu:20.04",
)

Is anyone able to help?

Is there a way to detect that this is running with pants? So I can flag in resource loading logic conditionally. Specifically python logic.

Any idea why I'd see

_pickle.PicklingError: Can't pickle <class 'pex.enum.Enum'>: it's not the same object as pex.enum.Enum

when running something as a pex? It works fine running as a module

Do you mean doing what

coursier

does inside pants, when it’s used elsewhere?

Please respond if you haven't already! Your feedback helps make Pants better!

I mean doing something similar to what

coursier

does in downloading JDKs but managed from within the Pants rules and not via an external utility as

coursier

is

ah sure