News for hackers. Stuff that matters.

donenext

Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @04:42PM (#44195586)
Thats fair. It just seems silly that a spec intended to "uniquely ID a package" supports a type that is the complete opposite of "unique". I guess another way to frame my take is should `generic` be consider a valid PURL? Keep it as a fall back sure, but distinguish between "fully qualified" PURLs and "partial" PURLs.

This then gives tooling a path to prompt users to provide missing context needed to fully qualify the PURL

Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @04:32PM (#44195508)
Can we completely eliminate generic as a type to remove this crutch?
Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @04:31PM (#44195500)
Hot take, `generic` as a type is a crutch most tooling uses out of laziness and has significantly reduced the usefulness of PURL spec. How do we improve this?
Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @02:44PM (#44194544)
Yes, 1000x yes
Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @02:44PM (#44194538)
completely agree here `git` type using the namespace of your choice would be plenty to enable tools to find these packages. Even though its not "officially" supported in the spec this is what we do internally