Add optional support to fetch the latest PURLs

[keshav-space]

Add support to optionally fetch latest PURLs at runtime so users do not need to upgrade to a newer version of purl-validator just to get the latest PackageURLs.

[VineetC137]

Hi @keshav-space 👋
I would like to work on this issue.
Plan:

• Keep current bundled PURL data as default
• Add optional runtime fetching of latest PURLs
• Cache fetched data locally
• Avoid breaking existing behavior
  I’ll start by locating where PURL data is currently loaded.
  Please let me know if this approach is okay.

[shuvakant6623]

Hi @keshav-space 👋

I’d like to work on this issue.

From my understanding, purl-validator is designed to work fully offline using a pre-built FST generated at build time, which means users currently need to upgrade the entire library whenever they want newer PURL data.

My approach would be to keep the existing bundled FST as the default behavior, preserving offline and air-gapped usage, and add an optional runtime mode that allows users to fetch and use a newer PURL dataset when they explicitly opt in.

The goal is to let users benefit from fresher PURL data without changing the default offline-first design, and to safely fall back to the bundled FST if runtime updates are unavailable or fail.

Please let me know if this aligns with your expectations.
Thanks!

[VineetC137]

Thanks for the clarification, that makes sense.
I agree that preserving the offline first, bundled FST behavior as the default is important, especially for air gapped use cases. My intention was also to keep the existing FST untouched by default and only allow a runtime override when users explicitly opt in, with a safe fallback to the bundled data.
Happy to coordinate or take on a smaller preparatory/refactor task if that helps (for example, isolating FST loading behind a single interface, or improving documentation around the current offline behavior).
I’ll wait for your guidance on how you’d like to proceed.