Add tests for latest purl-spec

[ziadhany]

Adds test coverage using reference data provided by purl-spec
https://github.com/aboutcode-org/purl-spec/tree/main/tests/types.

The test schema is available https://github.com/aboutcode-org/purl-spec/blob/main/schemas/purl-test.schema.json.

Note:

• There are some errors related to the Maven, npm, CPAN, and Conan ecosystems. We’re trying to solve them.

ERRORS!
Tests: 633, Assertions: 1277, Errors: 11, Failures: 9.

Related issue:

• purl-next: Update PURL libraries to pass new test suite - packageurl-php #40

[jkowalleck]

Thanks for the proposal.

Until purl 1.0 is released, all significant changes to this very repository are postponed. See

packageurl-php/README.md

Line 18 in b8e5381

> It will not receive further updates until the standardization process is complete and a stable version of the specification is released.

[pombredanne]

Thanks for the proposal.

Until purl 1.0 is released, all significant changes to this very repository are postponed. See

packageurl-php/README.md

Line 18 in b8e5381

> It will not receive further updates until the standardization process is complete and a stable version of the specification is released.

@jkowalleck The purl 1.0 spec has been accepted by Ecma TC54, so at this stage we should be starting to fix all the libraries, and @ziadhany effort is part of this.

[jkowalleck]

The purl 1.0 spec has been accepted by Ecma TC54

PURL has still not published a stable version, nor a release.
And the Ecma standardization process is still not complete - the current version is just a draft.

As long as the above is still open, there will be no significant changes to this library.

packageurl-php/README.md

Line 18 in b8e5381

> It will not receive further updates until the standardization process is complete and a stable version of the specification is released.

[jkowalleck]

There are some errors related to the Maven, npm, CPAN, and Conan ecosystems. We’re trying to solve them.

Thank you for all your effort.

This library never intended to implement any specific PURL type. it was intended to implement the upcoming standard - which is just the core spec.
since the purl test suite was finally split into core spec and types, this is finally possible safely.

Please refrain from adding any implementations, tests, etc for now.

[pombredanne]

Please refrain from adding any implementations, tests, etc for now.

@jkowalleck I asked @ziadhany to help on this .... I am not sure why we would not want to have full support for PURL here ... but if this an issue, we can instead maintain a fork for now, something like packageurl-php2 of sorts.

[jkowalleck]

I am not sure why we would not want to have full support for PURL here

First, PURL types are not standardized, they are merely registered. They have no stable version, they have no common definition, they are purely opinionated.
Implementing an opinion may conflict with a different opinion - i don't want to have an implementation for opinions, I want this to be a library implementing a standard, which is the PURL core specification and nothing more.

Second, PURL types no longer are registered in one location, but can be defined by everyone in arbitrary locations (that's what @pombredanne told me "each ecosystem could/should own and share its own type definition") - Don't want to implement things that get out of control easily.

Third, I don't want to chase type completeness in this library.
I follow the PURL type definitions, the conversations/discussions, tickets and pull requests for almost 6 years now. I think I have good understanding what's going on here, and my conclusion is, that it is undesirable to implement them PURL types in this library - especially with the mentioned facts above.

I asked @ziadhany to help on this ...

Working on unplanned/undesired work packages might lead to rejection easily.

You should have opened a ticket, and asked if/how to be helpful, before dropping a large pull request :-)
We then might have discussed the design/architectural changes I have in mind for the upcoming/future version of this library. We then might have discussed how to pull the test suite into this very repository (for sure, git-submodule is not the desired way). We then might have discussed how this library could be used as a used in a different library that tries to chase PURL type completeness (Something like package-url/packageurl-php-types depends on package-url/packageurl-php).

This being said, it is not too late, feel free to open a discussion/ticket to clarify all of this.

[jkowalleck]

this change set is not desired.

as discussed, a complete redesign is planned: #243