Use Upstream of tools-python, Not Fork about ntia-conformance-checker

[nicoweidner]

The fork was last updated in August, so is quite out of date by now (since a lot of things happened in the meantime). I looked at the fork and it seemed the only addition it has compared to upstream is a PR that was rejected in tools-python. See this comment on the PR for the main reasons. The author never came back and replied.

In general, I would advise to use upstream, of course. And I also think that the changes from the PR mentioned above are not desirable. But if ntia-conformance-checker really relies on those changes, switching to upstream may cause some issues.

To save you some time: The main change from the PR was that for any given input file, all parsers (for the various formats) attempt to parse the file, regardless of its ending. This covers cases where a file was given the wrong ending (e.g. a yaml file that has a .json ending). I prefer to throw that back as a user error, though, and I would be surprised if it's important for the conformance checker to include this functionality.

[goneall]

The only open question: Should this project switch to the upstream before the upstream accepts three commits from @linynjosh's fork? Or should the project switch to the upstream and, in the meantime, try to merge those changes? (Assuming those changes haven't been submitted and merged in the past sometime.)

@nicoweidner @meretp @armintaenzertng Any suggestions?

[goneall]

Thanks @nicoweidner for the analysis. From the description of the additional commits, it doesn't sound like it is essential to the operation of the conformance checker and we can probably just switch to the upstream.

[jspeed-meyers]

Roger. Thank you, @nicoweidner!

I'll put in a PR to switch to the upstream.