https://pantsbuild.org/ logo
Join Slack
Powered by
Hey! fisrt question here:) i`m trying out Pants bu...
# general
d
Hey! fisrt question here:) i`m trying out Pants build for the first time on our existing monorepo, while i was able to work with most of pants features(and they are just perfect!) i`m still having hard time on understanding how to work with monorepo dependencies resolve and management, should i populate BUILD files with the dependencies manually? or should 
./pants tailor
take care of that? i feel like i`m missing something here... Also, do you have any example for monorepo managed by pants build? I couldn't find anything more that basic setup online
h
Hi! What you're missing (and presumably this is because we haven't documented this well enough, sorry) is dependency inference - Pants will automatically infer dependencies on both first and third-party code
Does that answer your question? Or did I misunderstand what you were asking about?
Are you referring to external dependencies, or internal ones?
As for examples of monorepos, https://github.com/pantsbuild/pants itself is a good one
Most pants monorepos I'm aware of are private
But I think @proud-dentist-22844 has a public one?
p
Yeah, though I'm not done switching to pants. https://github.com/st2sandbox/st2/tree/pants
If you want to play with pants in an open source repo, I'd love the help 😄 just try something with pants and when you run into something that doesn't work, fix it 😉 (with my help).
b
Hey folks! I have a monorepo too, how I can use scm version with Pants ?
I have to implement my custom plugin or is there something already done?
h
Hi! What are you trying to do with scm version?
b
I would like to dynamically have the git tag version as a version, as I did with poetry.
and I would like it to be the same for all the projects of my monorepo.
h
The upcoming Pants 2.13 release will have support for setuptools_scm (https://github.com/pypa/setuptools_scm/)
You can see an example of how it works here: https://github.com/benjyw/black/blob/pantsify3/src/BUILD
It's available in the 2.13.0a0 release from yesterday, for example
👍 1
b
I'll try right away, thank you very much!
d
Hey @happy-kitchen-89482 sorry for late response just got back from the weekend:) Thanks for the replies, i did took a second look at 
dependency inference
docs but im still not quite sure i understand how to work with it.. I am referring to 3rd party dependencies, how are they being managed? should i manage a 
requirements.txt
file manually? or perhaps should i manage the contents of BUILD files manually? What im trying to solve is the dependencies hell in our monorepo, i have never worked with other build tools like pants before and i feel like im missing something in the dependencies front
h
Ah, gotcha.
Generally, the way to tame dependency hell is via lockfiles
A lockfile is tied to a named "resolve" - a universe of mutually compatible 3rd-party dependencies. You define a resolve by manually authoring a requirements.txt that contains the requirements your code directly depends on. You then generate a lockfile for that resolve, and the lockfile pins specific versions of each of those requirements and all their transitive dependencies. So a lockfile gives you secure, repeatable builds even when the state of the world changes.
Now ideally your repo would have just one lockfile, so that every part of your repo has to be compatible with just one version of a given 3rdparty dep. In practice that may not be possible - you may genuinely need different parts of your repo to consume different versions of something. Or, you may at least temporarily need that while you consolidate down to a single lockfile.
But even with multiple lockfiles, at least the dep management is rigorous - each target in your internal code has to declare which lockfile(s) it's compatible with.
One straightforward way to migrate to this is to have one lockfile for each requirements.txt in your repo, and then start consolidating them down
You don't usually need to declare explicit dependencies on 3rdparty deps. Dependency inference takes care of it. The only time you do is when there is no 
import
statement to infer from, or if your code is compatible with multiple resolves, and the same package is provided in more than one of those resolves.
So basically Pants takes your implicit dep hell and makes it explicit, forcing you to name your dependency "universes", and then gives you the tools to de-hell it, by consolidating down to - ideally - one global resolve.
Does this help?
Open in Slack
PreviousNext
Powered by