Be less restrictive with Looker version check

[agile]

If the version detected is less than the defined minimum, issue a warning noting the version being used is not supported rather than refusing to run at all. (maybe it should also warn that it may crash Looker?)

We are running an older version of Looker (6.16.x) and I wanted to see if it simply would not work at all or if we were able to at least gain some utility. To my surprise, it seems to work ok, I have not run into the 500 errors (#73) that led to #81, yet.

[codecov]

Codecov Report

Merging #118 into master will increase coverage by 1%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #118   +/-   ##
=======================================
+ Coverage   65.46%   66.47%   +1%     
=======================================
  Files           9        9           
  Lines         724      683   -41     
=======================================
- Hits          474      454   -20     
+ Misses        250      229   -21

Impacted Files	Coverage Δ
spectacles/client.py	56.71% <ø> (+4.68%)	⬆️
spectacles/validators.py	59.3% <ø> (-1.51%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a21092c...2730da9. Read the comment docs.

[DylanBaker]

@agile Are you on self-hosted?

The regression that needed #81 was introduced in 6.20 AFAIK, which makes sense that you are able to run on a previous version and makes a good argument for loosening this.

[agile]

Yes, self hosted. Good to know that it's something introduced in 6.20, I believe we've been planning to upgrade to that fairly soon but maybe we can leap frog up to 6.22 or better instead.

[joshtemple]

The API fix should've been backported to 6.20, so it's possible it may even work for 6.20 instances. I'm comfortable removing this restriction altogether (including the warning proposed here) until we hear otherwise from people on 6.20-6.22.

@DylanBaker, thoughts?

[DylanBaker]

@joshtemple Yeah, I think I am okay with that. Is there value in going back and seeing what version actually introduced the endpoints were are hitting? Are we at all worried that people are using really old versions of Looker?

Ultimately, I think I'm okay removing for the moment, but it would be good to ascertain whether they have actually backported it. I'd also be keen to find a way with Looker to test this on an ongoing basis against a range of instance versions.

[DylanBaker]

@agile Hey. As @joshtemple suggests, I think the best tact here is to just remove the exception and not have a warning. The fix should be backported so we probably don't need either. Would you mind updating the PR?

[DylanBaker]

@agile I should have also mentioned, we have a Slack community for people who are using and contributing to Spectacles. If you're interested in joining, you can do so here.

[agile]

Ok, version checking removed ;) Will join slack later

[joshtemple]

Thanks @agile, we really appreciate the help with this PR!