Packaging: Inject st2 version into rpm/deb packages (pants-plugins/release)

[cognifloyd]

This PR is working towards doing packaging via pantsbuild. Eventually, I hope to archive and stop using st2-packages.git.

This PR enables the nfpm backend in pants and updates pants-plugins/release so that it can inject the version number into the rpm/deb similar to how that plugin injects the version in python wheels that pants builds. To keep this PR focused on pants-plugins/release, it does not add any BUILD metadata like nfpm_deb_package or nfpm_rpm_package. Adding the BUILD metadata, and using the changes introduced in this PR, will come in follow-up PRs.

Relevant pants docs about nfpm:

• nfpm subsystem
• nfpm_deb_package target
  • version_schema field
  • version field
• nfpm_rpm_package target
  • version_schema field
  • version field
• InjectNfpmPackageFieldsRequest plugin hook

Relevant pants docs about developing our pants-plugins/release:

• Plugins overview
• Testing Plugins

Implemenation notes

It can be helpful to review each commit of this PR.

• 8290573: enable the nFPM backend in pants.

• 3e20568: pants-plugins/release was introduced in Add pants-plugins/release to handle wheel metadata generation #5891 to help with injecting wheel metadata (like the version number) into the generated wheels. Since we already have the logic to get the version number, and we want to do the same for nfpm, I extracted that into a separate pants rule called extract_version.
  

  st2/pants-plugins/release/rules.py

  Lines 103 to 104 in 3e20568

  	@rule
  	async def extract_version(request: StackStormVersionRequest) -> StackStormVersion:

• 6b508a2: Then I implemented an InjectNfpmPackageFieldsRequest with the inject_package_fields rule.
  

  st2/pants-plugins/release/rules.py

  Lines 196 to 205 in 6b508a2

  	class StackStormNfpmPackageFieldsRequest(InjectNfpmPackageFieldsRequest):
  	@classmethod
  	def is_applicable(cls, _: Target) -> bool:
  	return True
  	@rule
  	async def inject_package_fields(
  	request: StackStormNfpmPackageFieldsRequest,
  	) -> InjectedNfpmPackageFields:

  
  And, this registers our implementation with a UnionRule here:
  

  st2/pants-plugins/release/rules.py

  Line 234 in 6b508a2

  UnionRule(InjectNfpmPackageFieldsRequest, StackStormNfpmPackageFieldsRequest),

  
  This is where this rule uses the extract_version rule introduced in the last commit:
  

  st2/pants-plugins/release/rules.py

  Lines 208 to 215 in 6b508a2

  	version_file = "st2common/st2common/__init__.py"
  	extracted_version = await Get(
  	StackStormVersion,
  	StackStormVersionRequest(
  	version_file=version_file,
  	description_of_origin=f"StackStorm version file: {version_file}",
  	),
  	)

  
  Then the cleans up the version to match nfpm's expectations of semver formatted versions:
  

  st2/pants-plugins/release/rules.py

  Lines 217 to 221 in 6b508a2

  	version: str = extracted_version.value
  	if version.endswith("dev") and version[-4] != "-":
  	# nfpm parses this into version[-version_prerelease][+version_metadata]
  	# that dash is required to be a valid semver version.
  	version = version.replace("dev", "-dev")

  
  Finally, the rule defines the fields that get injected in nfpm_deb_package and nfpm_rpm_package targets.
  

  st2/pants-plugins/release/rules.py

  Lines 223 to 226 in 6b508a2

  	fields: list[Field] = [
  	NfpmVersionSchemaField("semver", address=address),
  	NfpmVersionField(version, address=address),
  	]

  
  If the version extracted is 3.9.0dev, then the equivalent hard-coded BUILD metadata would look like:

  nfpm_deb_package(
      ...
      version_schema="semver",
      version="3.9.0-dev",
      ...
  )

Note: A follow-up PR will inject version_release, another nfpm package field. I did not include that in this PR, because it involves a script to retrieve the release number from packagecloud.

[winem]

It looks awesome and pretty useful on the first glance. I will take the time for a full review on the weekend.

[winem]

Well done!

[cognifloyd]

CircleCI builds are broken thanks to a new release of setuptools (v78) that removes support for deprecated keys in setup.cfg. Our logshipper fork has deprecated key author-email (instead of author_email) in the setup.cfg. In a few situations, the st2-packages CI does not get the version of setuptools pinned in the Makefile.

I'm working on fixing this by add a constraint to the wheels that are inadvertently (in st2-packages CI) pulling in this too-new version of setuptools.