FYI, interesting migration strategy for 3rdparty d...
# general
h
FYI, interesting migration strategy for 3rdparty deps I found while helping a friend adopt Pants in their monorepo:
Currently, they freeze all transitive deps into their
requirements.txt
, and I'm starting by separating
requirements.txt
with a new
lockfile.txt
Getting their tests to pass with Pants is going to take some work and will need to be done incrementally Instead, I'm temporarily using Pylint with this config to quickly discover what their direct deps are vs. transitive deps:
Copy code
[pylint]
args = ["--disable=all", "--enable=E0401"]
I wonder if this might be worth documenting?
also h/t to @happy-kitchen-89482 for
./pants tailor
, that is such a game changer and h/t to @curved-television-6568 for the default module mapping feature for 3rd party reqs. That removes a lot of friction with this migration! and h/t to everyone for dep inference, this would not be feasible otherwise
And then you can use Pylint w/
--per-file-caching
to make sure all your first-party deps are working properly
Yeah, I think this migration step makes a lot of sense! It's essentially: "get all your dependencies working" Which will make everything later a lot easier, like getting tests to work. You've already done most the work
p
Yeah. That's kind of what I was trudging through. Calling out the "get all your dependencies working" step with some helpful advice on how to do that would be an excellent addition to the docs.
2
b
Great idea. You've been working so actively on that problem, I wonder if you have thoughts on what to share in that?