Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support exporting downloaded external tools #21251

Closed
huonw opened this issue Aug 1, 2024 · 1 comment · Fixed by #21258
Closed

Support exporting downloaded external tools #21251

huonw opened this issue Aug 1, 2024 · 1 comment · Fixed by #21258

Comments

@huonw
Copy link
Contributor

huonw commented Aug 1, 2024

Is your feature request related to a problem? Please describe.

Pants supports various "tools", some of which are just a binary downloaded from the internet. For instance, pex, helm, terraform, makeself, shellcheck, potentially ruff (#21237), ...

It'd be convenient if there was some way to export such binaries from pants so that one can invoke them outside of pants, e.g. for local dev without pants overhead or even just for experimenting with the tool to understand how one needs to configure pants.

Describe the solution you'd like

pants export ... can somehow export downloaded tools. Ideas:

  1. treat them as a resolve with their options name, e.g. pants export --resolve=pex or pants export --resolve=helm (may cause issues if someone has an existing resolve of the same name)
  2. treat them as a resolve with some sort of namespacing, e.g. pants export --resolve=__subsystem__/pex (less chance of an existing resolve with this name)
  3. give them a new arg, e.g. pants export --tool=pex
  4. something else??

Describe alternatives you've considered

N/A

Additional context

See discussion on #21237

@lilatomic
Copy link
Contributor

I think it makes sense to use a different arg:

  • they would be implemented differently (not actually resolves)
  • they would be used differently (invoked, instead of source dist/.../activate)
  • we could put them all together into a folder like "dist/bin" so people could add it to their path

my bikeshed vote is for --bin, or maybe --tool

lilatomic added a commit that referenced this issue Oct 12, 2024
This MR wires `ExternalTool`s into the export machinery.

It exposes them under a separate cli arg `--bin`. Although it uses some
of the same machinery as `--resolve`, there are several differences that
I think support a separate flag (and some separate internal):
1. `ExternalTool`s don't have a resolve. They therefore must not show up
for generating lockfiles. We have to implement this separation
interally, so we should probably surface that.
2. They would be invoked directly (instead of `source
dist/export/.../activate`)
3. We can put them all in a folder "dist/export/bin" so people can get
them all

Closes #21251 

Bikeshedding:
- [x] Do we like `--bin` (yes)
- [x] Is putting all the bins in the same dir what we want (yes, we want
a "bin" folder with all the binaries. But we have to put each binary's
digest in its own folder to prevent collisions of supporting files)
- [-] Do we want to make all TemplatedExternalTools exportable? We could
extend Subsystem.rules and add the UnionRule there (deferred from this
MR)

---------

Co-authored-by: Huon Wilson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants