@fast-nail-55400 (and pants maintainers) I saw you were exploring using Honeycomb as a backend for traces generated from your pants plugin. I work at Datadog and we offer Datadog for Open Source Projects, which is free (here are some example projects in the program). Because a group of us are onboarding pants at Datadog, it would be awesome to give back to pantsbuild this way and have you using Datadog. Plus, Datadog is pretty full featured with lots of integrations, so it should be a good experience. I'm curious if this is of interest. The application form is open, but I may be able to help if there are issues.

Thanks for the offer! I think we’d be happy to evaluate this. But I suspect @fast-nail-55400 doesn’t have free cycles for it. If (perhaps after onboarding) someone at datadog could help out with this, that could be great.

Awesome I'm glad there's interest! We've made a lot of progress onboarding pants at Datadog and we could help whenever

Perhaps we could check back in on this in September? A lot of folks are doing summer things right now, myself included.

Sure thing

Hi @busy-ram-14533! Wanted to check in on how your onboarding is going at Datadog?

Hey Benjy, thanks for checking back in. The onboarding has gone great… I’m actually on vacation right now but I’ll add some details when I’m back next week.

Enjoy!

Hey @happy-kitchen-89482! Just following up, finally. We've onboarded pants to a monorepo that focused on AI/Data Eng use cases, and was in dire need of better+more standardized python tooling. Previously internal devs had to deal with a mess of `venv`s and were using custom docker images to deal with third party dependency conflicts. So we've made great progress onboarding pants, and have it in some key development paths right now. For example, we're using pants to 1. Build PEXes of PySpark jobs 2. Build PEXes of more random python scripts that we can launch with Airflow (allowing us to avoid using the Airflow PythonOperators and avoiding dependency conflicts with the core Airflow python environment) 3. Build wheels of some python libraries we want to share internally 4. Build Docker images for Ray jobs (with PEXes for the job logic + dependencies) We've added pants to our CI, where it also does the linting, type checking, unit testing in addition to building artifacts that we publish. And again, overall, it's been great! The docs for pants are incredible, the community here and the support we get from maintainers like you is great. The biggest pain points we have are: 1. Our users really need to control their own Resolves. We want to make 1st party libraries that have 3rd party libraries with bounded dependencies (

lib A >v1, <=v2

) that get shared by multiple resolves. We're making wheels to share libraries instead, which adds all sorts of other pain. And we want to migrate from sbt to pants, but need a solution that can be about as flexible with handling 3rd party deps for different teams 2. Lack of IDE support/plugins (we would like for VS Code and JetBrains families of IDEs) a. I actually just vibe-coded a VS Code plugin but haven't tested it yet 3. Lockfile generation being slow

Great to hear! Feel free to ask questions on #C046T6T9U as you go. And if you might need more formal consulting/contracting help, a few folks on here offer that (myself included)

Absolutely, we're considering it (and sponsorship too) down the road