-
-
Notifications
You must be signed in to change notification settings - Fork 644
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
make it easier to interpolate artifact names #18659
Comments
The challenging part of this request is probably the migration path for users who are setting the path and filename using Alternative solution: Keep only the |
@cburroughs: #21175 is a draft solution. Let me know if the shape of it works for you. |
The template approach looks reasonable to me, and I like having fewer fields. Thank you. |
…21175) As described in #18659, when a user sets `output_path` on a packageable target, the user gives up the default behavior which uses a normalized version of the target's directory as the directory into which the place the built artifact. While the user could replicate the behavior manually, it would be a better user experience if the user can still have partial access to some of the default behavior. This PR teaches the `output_path` field how to derive its value from a template instead of hard-coding its behavior in Python. The `output_path` field learns the following template replacements: - `spec_path_normalized`: The path to the target's directory ("spec path") with forward slashes replaced by dots. - `target_name_normalized`: The target's name - `file_suffix`: For target's which produce single file artifacts, this is the file type suffix to use. This is empty if not applicable. The default value for the `output_path` field is now `"${spec_path_normalized}/${target_name_normalized}${file_suffix}"` which replicates the existing behavior. `string.Template` is used as the template engine. This PR also fixes some incorrect usages of `output_path` in several backends.
Implemented by #21175. |
…antsbuild#21175) As described in pantsbuild#18659, when a user sets `output_path` on a packageable target, the user gives up the default behavior which uses a normalized version of the target's directory as the directory into which the place the built artifact. While the user could replicate the behavior manually, it would be a better user experience if the user can still have partial access to some of the default behavior. This PR teaches the `output_path` field how to derive its value from a template instead of hard-coding its behavior in Python. The `output_path` field learns the following template replacements: - `spec_path_normalized`: The path to the target's directory ("spec path") with forward slashes replaced by dots. - `target_name_normalized`: The target's name - `file_suffix`: For target's which produce single file artifacts, this is the file type suffix to use. This is empty if not applicable. The default value for the `output_path` field is now `"${spec_path_normalized}/${target_name_normalized}${file_suffix}"` which replicates the existing behavior. `string.Template` is used as the template engine. This PR also fixes some incorrect usages of `output_path` in several backends.
Is your feature request related to a problem? Please describe.
Right now it is easy to tell pants to "package all the things" with
pants package ::
. This fills updist
with all of the goodies. However, instead of havingfoo.tar.gz
I'd like to havefoo-VERSION.tar.gz
so that everything is ready for uploading publishing. (Where version is maybe a constant likev.1.2.3
or just the git sha.)output_path
can almost do that, but then I have to re-implement the/ --> .
logic.Describe the solution you'd like
Give all "just a file" artifacts an
output_name
to go along withoutput_path
, the "path to output" logic then looks something like:build_file_dir.replace('/', '.') + name
output_name
is set:build_file_dir.replace('/', '.') + output_name
output_path
is set: `output_PathDescribe alternatives you've considered
versioned_tarball
macro.Additional context
Doing it with a macro isn't that bad. But I feel like there is some fundamental inconsistency where some "packages" like docker or python_distributions have a separate "version", but others do not.
spinoff from: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1680240146011409
The text was updated successfully, but these errors were encountered: