<@U076ANYLSPP> <@U076AAC9A94> <@U077155B201> <@U07...
# welcome
b
@astonishing-motorcycle-13344 @gorgeous-thailand-61086 @strong-park-87111 @thankful-vegetable-72262 @brief-branch-21752 @billowy-vegetable-62104 Welcome to the Pantsbuild community! ๐Ÿ‘‹ ๐Ÿ‘– We'd love to hear a bit about you, and what you do, and why you're here, if you feel comfortable sharing. If you have any questions be sure to join #general as well.
g
Hi everyone. I'm on a team at Nike that builds and operates many Python microservices deployed on AWS Lambda. We're beginning to integrate some of these into a monorepo, and I'm evaluating Pants as the build tool for that repo. I'm still trying to get a sense of what this would look like using the incremental adoption strategy, especially what that looks like to introduce new tooling to a team, when it's not fully adopted yet. Also thinking about whether it makes sense to try to converge all of our interpreter versions and dependency versions before starting with pants, so that we can adopt a single resolver for the whole repo, or do we start with multiple resolvers and try to converge into a single resolver later?
b
Welcome. Thatโ€™s a good question! How much code is shared between the various artifacts?
g
Everything is structured as installable python distribution packages. Some of those are libraries that are used by a number of the lambda packages. I'd say maybe 3 or 4 shared libraries used across over a dozen different applications. We do want to eventually get to single-interpreter/single-resolver, just not sure if there's an optimal order of operations
b
Hmm, I'm not personally sure of the details of how to onboard that. Could you ask the question again in #general? Thanks and sorry about that
๐Ÿ‘ 1