You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of the pkg_filegroup framework relies upon users specifying specifically where files end up in packages. It is up to the user to create the various pkg_files rules to manage this. This is great for general-purpose use, but can be quite verbose.
One idea for reducing verbosity is to specify package contents in terms of tables, like in #238. That, however, still relies on manual path construction and placement. Another way to specify this is to identify files in terms of their roles, namely what they're intended to do: e.g. configuration files might be installed in one location, binaries another, and libraries another from that.
We can imagine a system by which could associate a "role" with a particular target or target outputs. For example:
pkg_role would emit a provider that would inform pkg_role_filegroup about the nature of a role, in this case, where files end up, and what identifier (tag) should be used to inspect them. This information would be accumulated in an aspect and then processed to form a PackageFilegroupInfo provider that can then be passed to packaging rules as needed.
This simplifies the package implementaiton process by allowing users to associate packaging information with the rules that emit the outputs in question, at the cost of granular control. Information regarding destinations and other policies could be encoded into pkg_roles by way of selects and other logic.
This also comes with the cost of complex implementation, testing. There are a considerable number of edge cases that would need to be considered, as well as distribution (e.g. roles should be standardized) . Should this feature be desired, a design document should be created, along with prototypes.
The text was updated successfully, but these errors were encountered:
nacl
changed the title
Design: role-based packaging system
RFC: role-based packaging system
Aug 8, 2021
The implementation of the
pkg_filegroup
framework relies upon users specifying specifically where files end up in packages. It is up to the user to create the variouspkg_files
rules to manage this. This is great for general-purpose use, but can be quite verbose.One idea for reducing verbosity is to specify package contents in terms of tables, like in #238. That, however, still relies on manual path construction and placement. Another way to specify this is to identify files in terms of their roles, namely what they're intended to do: e.g. configuration files might be installed in one location, binaries another, and libraries another from that.
We can imagine a system by which could associate a "role" with a particular target or target outputs. For example:
pkg_role
would emit a provider that would informpkg_role_filegroup
about the nature of a role, in this case, where files end up, and what identifier (tag
) should be used to inspect them. This information would be accumulated in an aspect and then processed to form aPackageFilegroupInfo
provider that can then be passed to packaging rules as needed.This simplifies the package implementaiton process by allowing users to associate packaging information with the rules that emit the outputs in question, at the cost of granular control. Information regarding destinations and other policies could be encoded into
pkg_role
s by way ofselect
s and other logic.This also comes with the cost of complex implementation, testing. There are a considerable number of edge cases that would need to be considered, as well as distribution (e.g. roles should be standardized) . Should this feature be desired, a design document should be created, along with prototypes.
The text was updated successfully, but these errors were encountered: