Add pslint.py linter and use it on Travis CI

[rockdaboot]

This adds a python PSL linter for use with Travis CI.

The former 'linting' of the PSL done via libpsl pulls in a full C project on each commit to publicsuffix/list. Configure, compile and link steps are a waste of CPU time in comparison with this simple python script.

Simone (@weppos) opened a wiki page with a bunch of tests to perform.
The python script performs all test except 'Order' (the last one in the list).

[weppos]

I see you are still referring to the test_psl.txt file. I assume this line will have to be changed once the following change is completed:

Libpsl is prepared to take the new tests.txt format in it's test suite. I will prepare a new release as soon as you pull the PR into master.

Am I correct?

[weppos]

@rockdaboot I suggest you push an updated version of libpsl in a branch (the one with the support to run the tests from the new file format). We update this PR to pull that branch and we run all the tests.

In this way, we can test this PR from start to end before merging it into master.

[rockdaboot]

@weppos I made a new libpsl branch 'newfmt' (using tests.txt as default test file) and amended .travis.yml in this PR to explicitly use tests.txt with the new format.
Hopefully, that should be it.

[weppos]

@rockdaboot that works for me. I'll wait for @gerv approval, as I see there are some files where the copyright is assigned to you, and I want to make sure this is fine for him in terms of acceptance.

PS. I see make configure and make clean are quite verbose. Any chance to have something less chatty? I think I may play a little bit around with output redirection.

Also, what about the libidn2 and libidn tests? Since I'm not familiar with any of these specific build configs, what is your suggestions? Should they be removed?

[weppos]

@gerv FYI this is a replacement for #123

[rockdaboot]

@weppos Thanks for reviewing.

I see make configure and make clean are quite verbose. Any chance to have something less chatty?

./configure has a -q option to silence the configure run. CON: if something breaks, you possibly can't see why.
Also 'make' has a --silent option that stops printing all the details.
If you agree, I'll update the PR.

Also, what about the libidn2 and libidn tests?

Only, if we assume to get PSL entries that are different on IDNA2003, IDNA2008 or IDNA2008#46, e.g. the german label 'straße' (ask, If you are interested in the details). In this case we should define what PSL contains. I personally tend to test/support the latest IDNA(2008#46) since it cleans up some incompatibilities between 2003 and 2008. But I also know that most software out there relies on IDNA2003 implementations.
But anyway, we might only need one of those tests. On the other side - having all three tests allows us to be the first ones to detect/fall over incompatible PSL entries. That might be better than a 'customer' finding the problem first. The negative side is the additional waste of CPU cycles on Travis.
Long text, but I can't decide how to proceed, just try to share my knowledge here.

[weppos]

@gerv friendly ping for a 👍 on the copyright stuff

[weppos]

@rockdaboot I'm curious. Given the context of this PR, where would you see the test required in #160 (comment) implemented?

One of the reason why I am torn about the current test suite depending on libpsl (and therefore also the code here that keeps the same approach) is that we really have no test suite built into this repo. We rely on an external test suite, that doesn't necessarily have to evolve in parallel with the core PSL needs.

I'm still torn about using the libpsl in that way. I'd be curious to know where you'd see the test discussed in #160 to be implemented.

[gerv]

Copyright assigned to someone else is no problems as long as the license is open source, which it is (MIT-style). So go right ahead from a licensing perspective.

[weppos]

Thanks @gerv, I'll merge this PR tomorrow as it represents an enhancement with what we have so far.

[rockdaboot]

Given the context of this PR, where would you see the test required in #160 (comment) implemented?

You are talking about PRIVATE entries must end in a public suffix from the ICANN section.
This is IMO not a syntax test - it needs a full featured PSL implementation. Thus, such a test does not belong into the linter.

I could add it to the libpsl test suite - it's just a few lines of code (in theory).
But how do you define 'ending' ? Let's say there is a.b.c.d in the PRIVATE section. Is the test successful if we find 'd' as ICANN public suffix ? Since we have the implicit '*' rule, there must be some logic that isn't obvious to me right now.

[rockdaboot]

@weppos Regarding your concerns about using libpsl...
libpsl is closely tied to this publicsuffix/list project. So any change in syntax or semantics here should be reflected by libpsl ASAP. If changes are coming or anything fails, please contact me directly (e.g. via https://github.com/rockdaboot/libpsl) and I care about it.

[weppos]

@rockdaboot Indeed, I appreciate your support. However, libpsl is an implementation of the list. There are PSL-specific needs or tools I don't think may be a good fit outside the scope of maintaining the PSL itself.

I think the specific validation mentioned in #160 could be one of them. I'll start adding a simple test here.

I have one more question for you. Let's assume I make some changes to the PSL locally and I want to run the tests before committing. Do you have any suggestion? Should we package the test run process in a Make task so that we can easily run it with a single one-line command, even locally?

[rockdaboot]

@weppos I just made new libpsl release, so we won't need the extra branch 'newfmt' any more.

I think the specific validation mentioned in #160 could be one of them. I'll start adding a simple test here.

But how do you define 'ending' ? #160 is unclear to me (see comment above).

Should we package the test run process in a Make task so that we can easily run it with a single one-line command, even locally?

Better a shell script, e.g. 'run_tests.sh' in the main dir. We should call it from .travis.yml and it would be usable locally. I'll see if I find some time in the afternoon.