Running export for specific Python tools (or lockfiles) only
#17398
Labels
Comments
|
Funny, I am working on exactly this right now! |
benjyw
added a commit
that referenced
this issue
Nov 3, 2022
Currently, export takes cmd-line specs, so the python export implementation, which exports virtualenvs, exports the requirements of those targets. This has a couple of issues: A) User intent is almost certainly that export should emit the entire lockfile, whereas we will omit anything that isn't actively depended on by some target in the specs (which could be the case even with `::`). B) Tools don't relate to specs, so we export every tool every time, no matter the specs, which is obviously clunky. This change re-envisions how export should work. Instead of passing specs, you pass the `--resolve` flag one or more times, and we export a venv for each resolve, whether it's a user resolve or a tool resolve. The old codepath still works, but we can consider deprecating it in a followup. Closes #17398
benjyw
added a commit
to benjyw/pants
that referenced
this issue
Nov 3, 2022
Currently, export takes cmd-line specs, so the python export implementation, which exports virtualenvs, exports the requirements of those targets. This has a couple of issues: A) User intent is almost certainly that export should emit the entire lockfile, whereas we will omit anything that isn't actively depended on by some target in the specs (which could be the case even with `::`). B) Tools don't relate to specs, so we export every tool every time, no matter the specs, which is obviously clunky. This change re-envisions how export should work. Instead of passing specs, you pass the `--resolve` flag one or more times, and we export a venv for each resolve, whether it's a user resolve or a tool resolve. The old codepath still works, but we can consider deprecating it in a followup. Closes pantsbuild#17398
benjyw
added a commit
that referenced
this issue
Nov 4, 2022
…17416) (#17461) Currently, export takes cmd-line specs, so the python export implementation, which exports virtualenvs, exports the requirements of those targets. This has a couple of issues: A) User intent is almost certainly that export should emit the entire lockfile, whereas we will omit anything that isn't actively depended on by some target in the specs (which could be the case even with `::`). B) Tools don't relate to specs, so we export every tool every time, no matter the specs, which is obviously clunky. This change re-envisions how export should work. Instead of passing specs, you pass the `--resolve` flag one or more times, and we export a venv for each resolve, whether it's a user resolve or a tool resolve. The old codepath still works, but we can consider deprecating it in a followup. Closes #17398
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Sometimes I modify requirements for a specific Python tool, but I need to re-export all of the virtualenvs including other Python tools and the default one (
python-default).It takes quite some time.
Describe the solution you'd like
I'd like to re-run
./pants exportfor a specific lockfile only.(e.g.,
./pants export --resolve=flake8,mypy)The text was updated successfully, but these errors were encountered: