Hi folks, we're evaluating Pants as an easy-to-configure (git) monorepo build system and have some requests for guidance. I'm pretty new to Pex and Pantsbuild so bear with me please 🙂 Building and shipping docker-images which are meant to run use on CUDA machines: the workflow we're interested in is developing on CPU-only machines, building docker images with pytorch+Cuda support, and then exporting those. The suggested workflow with Docker + Pants is to COPY a pex file/folder to the docker image in the build step and then run from there; however I'm not sure how to reason about

pants generate-dependency

and then

pants package ...

running on an X86 CPU machine, and then expecting the Pytorch/cuda dependencies to work in my docker image. How can we handle these issues? Second question, probably more generic: is Pantsbuild a suitable system for shipping python microservices + js/ts/react frontend code? The goal is to run on kubernetes

Are you the Andrew Ho from torchdata? What CUDA deps are you worried about?

haha yes that's me

If you're generating lockfiles or similar, I recommend you do it on a linux machine (or linux docker image). Otherwise, the deps will resolve differently. You may have to customize the requirement with

sys_platform=linux

in some cases, e.g., flashinfer

makes sense

I figured. I was curious at first and felt like asking. I would guess that torchdata wouldn't be thinking about pants lol

Regarding first part: we run three resolves for torch -- cpu, gpu, and base (= pypi). The CPU/GPU only packages won't work on mac at all, and we have mac devs. Everyone defaults to pypi, but we parametrize all our Python with these three (or more... 😢) resolves. We've set it up so

--with-cpu

will force the CPU resolve,

--with-gpu

forces GPU, etc. For container builds we just set

resolve="gpu"

on the pex binaries. For the docker part specifically you also want to look at Pex's complete_platforms.json, to ensure the pex build happens exactly for the container you're using. It almost always works anyways if you're building on a similar platform, but when it doesn't it's a pain to fix. The second question I have less info on, but we do build a bunch of "utility" containers that are managed by our core go backend. So they aren't services in the traditional sense, but it's worked nicely to bring some of our tools closer to the ML repositories. We did briefly try to move our frontend from the Bazel monorepo to the Pantsbuild repo, but it wasn't worth the cost/effort for us compared to piggybacking on our main frontend team. If we didn't have that I think we could have made it work, it's definitely better than we have with Bazel. Just... lots of differing idiosyncracies.

@gorgeous-winter-99296 thanks for the advice that’s really helpful! For Frontend: are you saying that front end is on a separate monorepo already so migration wasn’t worth it, but if you were starting from scratch it might work on pants? Tbh I’m not sure how many shared libraries and differing lock files react workflow usually has

Yes, exactly. Frontend + go backends are in a six-year old bazel repo shared with most of our dev teams, including all our prod websites. So all tools for frontend already existed there and we've adopted to the bazel requirements. The pants usage is a few years newer and driven fully by me for the ML team. If we started over I would probably do it all in Pants, but yeah... Rebuilding tools for argo, infra diffing, ci/cd for more langs, and so on. And we're only like 1,5 fte working with those systems either way, so we can keep suffering.

Thank you that is very relevant. At this point I’m evaluating whether we should even do monorepo at all, or just stick with microrepos. Microrepo python was pretty terrible IMO but I mean we made it work for a long long time. I’ll have to chat with the devs and see what they think , since we’re starting from scratch the sky’s the limit

Follow Conway's Law. Fwiw, I think JS can take polyrepo due to the way npm resolves deps in lock files, but I dont think you'll have a good time with a python polyrepo.

Everyone seemed to like the python demo , our JS expert is going to take a crack at pants, he mentioned he used NX before for JS monorepo so was pretty curious to try out pants

We have tried to make Python polyrepo work 3 times at my current job, and each time it's been terrible as soon as you start talking about deploys etc... We tried internal registries (too much work for to maintain and use), submodules (people suck at git), vendoring (changes made in wrong place), git deps (see git). Eventually ended up in a custom monorepo where I wrote all build stuff from scratch, massive maintenance burden ("learning new tools is hard"). Then they wanted to open-source stuff, so we went back to polyrepo for a bit, half pants/half PDM. When they finally accepted this was also shit we went to a single Pants monorepo and life is glorious (as the infra/tools engineer).