Feature: support variable naming in pkg_deb

[zegl]

Description of the problem / feature request:

pkg_deb takes a version parameter for setting the version of the version of the generated deb-package.

It would be appreciated if this parameter would support "stamping", so that an external script (--workspace_status_command) can dynamically generate this version.

Similar to how the container_push rule supports stamping in it's tag parameter.

Feature requests: what underlying problem are you trying to solve with this feature?

Simplify creation of pkg_debs, if this was supported I wouldn't need to save the version to a file and use the version_file parameter.

What's the output of bazel info release?

release 0.22.0

[aiuto]

Whatever mechism designed must work for pkg_rpm() as well.
What we do internally at Google is allow $var substitutions in the version strings and then provide those variables in the builds that make distributable versions.

Doing this well probabl requires some design. Open questions:

• should we jus allow variable substitution from the environment?
• should it only be from workspace_status_command?
• What do people even want as paramaterizable version numbers? Is a date/time based substitution sufficient if you want it automatic? If not, why is it better to parametirize it than to update the BUILD file?

[ashi009]

I think there are already some mechanisms to stamp the packages yielded, say using a dynamically generated version_file which consumes workspace_status. However, doing so means we have to write such genrule everywhere. It would be nice to have it integrated in the pkg rules directly.

Whatever mechism designed must work for pkg_rpm() as well.
What we do internally at Google is allow $var substitutions in the version strings and then provide those variables in the builds that make distributable versions.

Doing this well probabl requires some design. Open questions:

• should we jus allow variable substitution from the environment?

Personally, I don't like it. Setting environment variables is not as obvious as a flag passed to bazel.

• should it only be from workspace_status_command?

Keep it consistent with other rules using variables from workspace_status_command would be great.

• What do people even want as paramaterizable version numbers? Is a date/time based substitution sufficient if you want it automatic? If not, why is it better to parametirize it than to update the BUILD file?

Updating BUILD file on every release sounds like toil. Also introducing changes to codebase during the release is problematic -- consider the case where a cherry-pick is needed for an old release branch, such change on the BUILD file may prevent the cherry-picked patch from being applied.

[aiuto]

What I could see is a shared attribute env_vars:string_list.

If you set that on any rule you get the dependency on stable_status and enable the lookup, but only for those variable listed. That nicely documents that the rule depends on something outside the BUILD file (perhaps a default can be specified there). I could also see this variable expansion extend into the template and spec files.

This needs a better design with some examples before implementing it. Any implementation should also cover all the rules, not just one package type.

[prashantv]

Indirectly related to this, when a debian package is created, it's currently named with the version,

rules_pkg/pkg/pkg.bzl

Line 381 in 098022c

out_deb = "%s_%s_%s.deb" % (package, version, architecture)

There are tools that assume that the file is named in this way, e.g., in dak:
https://github.com/Debian/dak/blob/master/daklib/regexes.py#L126-L128
https://github.com/Debian/dak/blob/master/dak/import.py#L116-L124

If the version isn't known till build time, then it can't be used as part of the output file. Ideally, there would be a way to output a tar file with the files named correctly based on version as well.

[aiuto]

More flexibility in output file naming is part of #193, #143, and #101. The solution to that proposed in #198 will also handle this stamp case.

[terinjokes]

#198 was merged, but it's not possible to use the functionality with pkg_deb

[aiuto]

Yes. File renaming from configuration in all rules is on my list. Getting date and time stamps in the name is still a difficult task. That is simply not available at analysis time. I have an idea about how to hack around that but exploring it is not a priority for me.

…

On Mon, Dec 7, 2020 at 6:55 PM Terin Stock ***@***.***> wrote: #198 <#198> was merged, but it's not possible to use the functionality with pkg_deb — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHAQLN2VLKNVAUNE323STVTQLANCNFSM4IBLVJIA> .

[terinjokes]

I ended up calling out to dpkg-name as part of my releases pipeline, so I was running into the normal issues with the version not being available at analysis time.

[aiuto]

Version should be easy. Timestamp is the hard part.

…

On Mon, Dec 7, 2020 at 11:28 PM Terin Stock ***@***.***> wrote: I ended up calling out to [dpkg-name[( https://manpages.debian.org/buster/dpkg-dev/dpkg-name.1.en.html) as part of my releases pipeline, so I was running into the normal issues with the version not being available at analysis time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHCL4O6FYJUKLNZPD2TSTWTPRANCNFSM4IBLVJIA> .

[jheaff1]

I too am interested in this functionality, specifically being able to produce a tar file that contains version info provided by the workspace status. Eg: my-tarball-1.2.3.tar.gz