nfpms overrides and replacements deprecation

[evanelias]

What happened?

nfpms.replacements was deprecated in #3589, and the deprecation warning does indeed work properly if you use nfpms.replacements directly. However, the deprecation warning isn't generated if format-specific overrides use the replacements field.

For example, using nfpms.overrides.rpm.replacements doesn't seem to trigger the deprecation warning. But I assume this usage is still deprecated.

On a related topic, is there any non-deprecated way to achieve this functionality? For example, if I want to replace "arm64" with "aarch64" only on rpm and apk, but not deb, is there any way to do this in file_name_template? I couldn't find a template variable that reflects the format or extension for nfpm use-cases.

I understand that the preferred approach now is to use .ConventionalFileName, and that makes sense for new projects. But for an existing project, changing to this will result in different file names than were used previously, which is non-ideal (it will break downstream users whose automation assumes the name format isn't changing)

How can we reproduce this?

This is just a partial snippet to demonstrate the problem (no deprecation warning is generated)

nfpms:
  -
    overrides:
      rpm:
        replacements:
          arm64: aarch64
      apk:
        replacements:
          arm64: aarch64

goreleaser version

$ goreleaser --version
goreleaser version 1.15.2
commit: 90531fc87975e9b7e1dda5f7a108ae2a8064b0f2
built at: 2023-02-07T18:12:36Z
built by: goreleaser
goos: darwin
goarch: amd64
module version: v1.15.2, checksum: h1:VYCFKTzzZFnFfSqfjvOmT8ip7VcZv1Y9JV13hAuDDB8=

https://goreleaser.com

GoReleaser Check

• goreleaser check shows no errors

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

Thank you for creating GoReleaser and nFPM, it's wonderful software!

[caarlos0]

ah, nice catch!

[evanelias]

Thank you for the fast response!

Is there any non-deprecated way to achieve this same functionality though? I didn't see any template variables that could be used in nfpms.file_name_template to do conditional logic on deb vs rpm vs apk.

[caarlos0]

it should work the same as with the archives name templates... are you getting an error? if so, please share the config + output and I'll have a look :)

[evanelias]

No error, I just can't find a variable that represents the format ("rpm" vs "deb" vs "apk") in order to do conditional logic in the template for use in nfmps.file_name_template... how do you duplicate the behavior that nfpms.overrides.rpm.replacements used to provide?

For example, if I want to replace "arm64" with "aarch64" only on rpm and apk, but not deb, how do you do this in nfmps.file_name_template?

I attempted something like {{- if eq .ArtifactExt "deb" }}arm64{{ else }}aarch64{{ end }}, but it does not work, since {{ .ArtifactExt }} is an empty string in nfpms:

file_name_template: >-
      {{- .ProjectName }}-
      {{- .Version}}.
      {{- if eq .Arch "amd64" }}x86_64
      {{- else if eq .Arch "arm64" }}
        {{- if eq .ArtifactExt "deb" }}arm64{{ else }}aarch64{{ end }}
      {{- end }}

Thanks for the assistance, much appreciated!

[evanelias]

On second thought -- after tweaking some of my automation pipeline, I was able to successfully switch to {{ .ConventionalFileName }} without breaking third party integrations, and that's cleaner anyway, so no worries!

Not sure if anyone else out there was relying on nfpms.overrides.[format].replacements to do funky naming logic, maybe this is a non-issue anyway :)

[caarlos0]

yeah, conventional file name is clearer, you're right though, there should be a variable for that.

will add another issue, thanks!