Remove PackageArtifactInfo

[nacl]

Packaging rules typically emit two artifacts, one named after the rule's name and is overall easy to identify, and one that is templated with a bunch of other metadata, like timestamps, change numbers, and versions, and is not so easy to identify programatically.

PackageArtifactInfo helps alleviate this problem by giving users a provider interface for identifying the complex-named artifact. Accessing it, however, requires that users implement custom rule logic to access it.

One potential way for working around this is use output groups. These can emitted in the appropriate providers, and then specific artifacts can be consumed by specifying the output_group attribute of the filegroup rule, with no custom rule logic required.

[aiuto]

Perhaps drop PackageArtifactInfo.

[aiuto]

Also see: bazelbuild/bazel#14204

[aiuto]

The more I look at this, OutputGroupInfo is the way to specify outputs.
#484 shows why in examples/where_is_my_output.

[nacl]

Another complication (and I think we had this problem regardless) is how to direct different implicit outputs to different locations. With this, you'd either have to create your own custom rule that maps everything to the right locations and emits PackageFilesInfo or somesuch, or have a lot of filegroup+pkg_files boilerplate.

It might be worth creating an more specific example use case for this. #484 may be it, but even if it isn't it is definitely a step in the right direction.

[aiuto]

The more I look at the practicalities of it, the more I think that OutputGroupInfo with consistent names for each group is the right choice. I came up with PackageArtifactInfo as an alternative, but it is less useful than OutputGroupInfo because you can't get at the individual components easily from another rule or from the command line.

…

On Fri, Dec 17, 2021 at 12:17 PM Andrew Psaltis ***@***.***> wrote: Another complication (and I think we had this problem regardless) is how to direct different implicit outputs to different locations. With this, you'd either have to create your own custom rule that maps everything to the right locations and emits PackageFilesInfo or somesuch, or have a lot of filegroup+pkg_files boilerplate. It might be worth creating an more specific example use case for this. #484 <#484> may be it, but even if it isn't it is definitely a step in the right direction. — Reply to this email directly, view it on GitHub <#396 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHA4ECX4XYEDIY43SSLURNWBVANCNFSM5BNACBNA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[aiuto]

Trying to decide what do to here. I am in favor of removing PackageFilesInfo because OutputGroup does everything needed. The less we build new, the better.

[aiuto]

I changed this task to deleting PackageFilesInfo. It was overdesigned.