Skip to content

Conversation

ghouscht
Copy link

See #369 for details.

Please let me know what you think. This proposal is for now solely based on my ideas and I'm open for feedback. It might even make sense to define two distinct types terraform-provider and terraform-module for more clarity.

@ghouscht ghouscht force-pushed the terraform-purl-type-def branch 3 times, most recently from 55e9030 to b9bc350 Compare June 27, 2025 20:40
PURL-TYPES.rst Outdated
- ``registry_url``: A registry URL where the provider/module may be found, but
not intended as the only location. This value is encouraged to identify a
location the content may be fetched in case the default registry is not used.
- The ``subpath`` is used to distinguish between a provider and a module.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one thought: it seems fairly abnormal to require a subpath. Is this something that is actually required to identify the terraform components or could it be made optional? In other words: is there overlap between provider and module where pkg:terraform/hashicorp/aws@version is unable to identify software because there are both providers and modules available at hashicorp/aws (or other names)? The fact this is required makes me think there is some overlap and if the case, maybe it's better to add this as the namespace? e.g.

      pkg:terraform/provider/hashicorp/[email protected]
      pkg:terraform/module/terraform-aws-modules/[email protected]
      pkg:terraform/module/terraform-aws-modules/[email protected]?registry_url=https://registry.example.com

... or lean into the other suggestion having multiple types, of terraform-provider, teraform-module, etc..

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. I think in practice there is no overlap between modules and providers, but afaik there could be overlap. I agree that it might make sense to add it to the namespace instead of using a subpath.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did think a bit more about this and I belive in reality there is no overlap between module and provider names. Because I had to update the PR to use the new JSON schema I got rid of this distinction in the subpath. Let me know what you think.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems simpler to me, thanks! 👍

@pombredanne
Copy link
Member

After the merge of PR #514, PURL types are now defined in JSON: 😇 😁

With the new approach... this needs to be updated. Can you take a stab at it? Thanks for your understanding !

@ghouscht ghouscht force-pushed the terraform-purl-type-def branch from b9bc350 to 0c9929d Compare July 30, 2025 18:24
@ghouscht
Copy link
Author

After the merge of PR #514, PURL types are now defined in JSON: 😇 😁

* See  [Refine Purl type schema #514](https://github.com/package-url/purl-spec/pull/514)

With the new approach... this needs to be updated. Can you take a stab at it? Thanks for your understanding !

PR is updated with the new JSON format. Let me know what you think

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants