Questions for best practice around lockfiles in th...
# general
b
Questions for best practice around lockfiles in the crash course video linked this this channel. • The example repo separate requirements.txt, requirements-dev.txt, requirements-test.txt, etc. That is different from the recommendation in the official doc of using just one. Is there any reason to separate them out, e.g., prod binaries don't depend on dev/test libraries? Or is the target dependencies will automatically prevent dev/test libs from being bundled in the final pex? • It also keeps different lock files for pytest, isort, etc, all explicitly referenced in pants.toml. Is that a good practice to have? Or should they be included in the requirements.txt?
e
For the 1st point there is no best practice. Pants gathers all requirements declared anywhere and locks them. Then when using the single lock it subsets just the requirements needed for the job at hand, whether running the tests in 1 file or building a PEX. So just do what makes sense to you in terms of breaking up requirements.txt files, using BUILD targets directly, or whatever combo. For the second, the video is probably just old - Pants changes alot. Now tools can be resolved from your main lockfile. In the past they could not.
b
Thanks!
e
Ok, looks like the video is sort of new, but the Pants being used is 2.16.0, which is sort of old. I'm not sure if 2.16.0 supports tool locks coming from the main resolve, but even if it does, this just underscores the point above. Pants moves fast; so even maintainers like Alexey are often behind in their knowledge. I know I am all the time.
b
Overall, I find the docs and examples to be more than adequate to get me started. So great job there!