Hi all. I recently moved to a new company in the ...
# welcome
k
Hi all. I recently moved to a new company in the tech industry where things have been done very differently for years. Personally I'm fairly interested in code quality and infrastructure, but that is not my job. I tested pants privately and found I could with very easily add linting, formatting etc to my repos. I also expanded this into my new company for the repos I am responsible for. Sadly I have seen for now that pants probably will not work for us (company wide) at this stage since there are to many limitations. Our company currently has many repos, basically no testing or branching strategy (I know, it's horrible, my part of the company is absolutely not like that), but I cannot move 10+ repos, 200people into a monorepo by myself, it would need a intermediate steps. And with the dependency system of pants that seems to be impossible 😞 Other than that I love the idea of pants and I have killed my own code that was duplicated in all repos to get formatting etc. Now pants work on my repose out of the box with minimal setup. I'm happy to be proved wrong, I have probably missed alot of the capabilities that pants can offer.
👋 1
c
Thanks for sharing your story!
e
Depending on how all your work dependencies are set up, you might be able to move just one project/repo at a time (and continue publishing whatever packages used to be published, so they can be used by the other repos that are not yet migrated).
This is the situation I'm going through at my org. We've migrated my small team and a couple of modules, and as we go, more and more people are starting to see the benefits and wanting to get on board.
k
That was my plan as well: 1. Add pants to all repos for formatters, this is free, just one build file that owns all python files and a toml file. 2. Over time also add linters, typecheckers etc, this requires cleanup that needs to be done repo by repo. 3. Run unit tests in each repo using pants, we use pytest for what we have today. This would make it possible to add key features like formatters etc, and get the team used to using them without doing a bigger decision that we are moving to a monorepo. TBH, I've worked in monorepo and I'm a big fan, but I also believe you cannot necessary trade down in complexity (at least if you are not doing stupid stuff), just shift it. Currently we have alot of complexity in polyrepo with artifacts, releases, you name it. Moving to a monorepo moves the complexity to the infrastructure, CI, etc and imo really needs a good architecture and build system. I do not believe my company are in a spot atm that making that decision now would be the right step. Or at least I'm afraid of adding that on top of what we have is a bad idea without a larger restructure.
e
Yeah, that's totally understandable. Good luck with everything, and maybe we'll get to see you again in the future!
👍 1
h
Thanks for the feedback! Are there missing features that would have made Pants more viable for your organization?
k
There are probably many things I have not figured out yet. I hope that with time I will learn more about the capabilities of Pants, maybe some of the things I can't do is actually possible. My main issue is that we don't have a monorepo where I work, and I'm not sure pants like polyrepos (understandable). F.ex we have one repository that has all dependencies, all repos use environments/get their dependencies from this repo, we don't have dependencies in the separate repos. At least for now I have not figured out how I can run tests using dependencies from a different repository.