I'm trying to get lint/format-on-save behaviour, so that we don't need to wait to find out about lint/format failures in CI. I'm trying to do that by exporting a tool virtualenv, but the link to create a tool lockfile there seems to imply we'd need to essentially recreate pants' built-in lockfiles for each tool to be able to do that. Am I missing something? Is there some way to export virtualenvs for tools without having to manage duplicates of the internal pants lockfiles?

We've got some instances of conversations around exporting internal tools (or using custom versions of internal tools) - if you search the slack chat. e.g. https://pantsbuild.slack.com/archives/C046T6T9U/p1719341852774469

Oh, that's exactly what I needed, thank you so much! I'm too used to bad experiences with slack search to the point I always forget about it 😞 On your comment here, I think the answer is yes to both, with the new thing documented as the answer to the second question. Would've saved me some time (and you answering the question twice 😅)!

Maybe it's just not released yet 🤷

The 2.22 docs have started dropping references to the need for custom lockfiles to export tools (though it's not updated across the board yet) so that seems likely - might've missed the window for 2.21 or not had enough tools updated yet to merit inclusion.

FWIW, this is working for me, so I know that it's possible. Just because I had some trouble with this previously, too, the

--resolve

is whatever has that particular requirement in it. It may be

python-default

, or it may be a different lockfile if you have a separate one for specific tools. You first have to generate a lockfile, then you have to export a virtual environment off of that lockfile.

What I'm asking for, and what I got the impression that PR enables, is to not need to have a lockfile for tools at all, and instead use the "internal" one. e.g. you should be able to

pants export --resolve=isort

to export that, without needing to externally manage requirements specific to those tools It doesn't sound like that's what you're doing, which is more in line with what the documentation currently directs you to do.

Sorry, must've misunderstood what you were getting at. I haven't found it too onerous to add a few lines for the specific tools that we use, but it would certainly be nice to not have to worry about it at all. Granted, our team is in a position where a handful of tools we need in the tool virtual environment aren't already present in pants, so it's kind of a moot point for us.

Yeah, it's probably not too big a deal to have another set of requirements, but I don't want to be the one on the hook if/when it drifts relative to what's in pants 😄 I think having people run pants commands directly rather than integrating with their editors is probably an ok tradeoff, particularly since it looks like we'll be able to do this without the extra requirements files in the nearish future.

And to be clear, I'm fairly sure that if you "install_from_resolve", pants is running the same version of the tool (that you choose) when you invoke the cli commands. So it stays consistent.