:wave: Hi everyone! I’m evaluating Pants, and I w...
# general
g
👋 Hi everyone! I’m evaluating Pants, and I was wondering if is there a recommended patter or way to setup a monorepo with many sub projects each with it’s own requirements file (sometimes even more than one). The default behavior would have issues with the dependency resolver by not being able to determine which 3rd party dependency of the many requirements files is referring to. Is it possible to indicate the resolver to limit the search up to a specific source root?
b
❤️ 1
That said, the smoother path for Pants/Python is to have a single resolve with a single set of dependencies for all code that interacts (i.e. if one subproject imports another, they should be in a resolve together). This means it's impossible to get into incompatible-dependency problems like "subproject 1 specifies
A==1.0
but subproject 2 specifies `A==2.0`"
g
Thanks for the reply! Yes I think that setting does match what I’m trying to do. I’ll give it a try. I agree with the preferred way but right know I’m experimenting in introducing pants in a codebase that has ~ 30-50 individual projects mostly in python, sharing dependencies between themselves either by REST api or direct use of the module but they are developed and deployed as individual containers. Usually this conflicts do not happen because the requirements are either never shared (independent containers) or the shared lib has a range of versions of which one specific version is set on the “service” itself. AFAIK there is no way to tell pants: “This import means that you should prefer this version”.