Fix Windows regression

[malthe]

Revert most of the spec/filename changes introduced in ad7a498, instead supporting pathlib.Path and zipfile.Path directly.

Note that this change also adds Windows to the testing matrix (replacing Ubuntu 20.04), motivated by #395 in which a regression affected the Windows platform, we want to run tests on Windows in addition to Ubuntu Linux.

[coveralls]

Pull Request Test Coverage Report for Build 7186272057

• 101 of 103 (98.06%) changed or added relevant lines in 7 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.1%) to 87.584%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/chameleon/template.py	32	33	96.97%
src/chameleon/zpt/template.py	6	7	85.71%

Files with Coverage Reduction	New Missed Lines	%
src/chameleon/template.py	1	90.2%

Totals
Change from base Build 7141626003:	0.1%
Covered Lines:	4287
Relevant Lines:	4787

---

💛 - Coveralls

[malthe]

@fschulze there were some issues on Windows and I decided to go back on the filename to spec renaming.

The way I see it, the spec syntax is supported two places:

1. In the template loader.
2. In the load: <spec> expression.

With this change, templates don't know about a spec (except for the prepend_relative_search_path branch which I think could be refactored out into the loader).

Instead, a template file class knows about package_name (optional) and filename. The importing logic remains unchanged from your original commit: ad7a498.

On the objectively positive side, we now test on Windows and tests are green.

[fschulze]

Could you yank the broken release? You increased the minimum Python to 3.8 and I now got a failure in another project which still supports Python 3.7.

[malthe]

Here's the test failure that motivated the dropping of Python 3.7.

But it's also EOL, so to be honest I don't feel we should make much of an effort to support it – unless there are some good arguments that I don't know about?

Shouldn't pip or some other install tool automatically downgrade to 4.3.0 if unpinned – unless of course there's some transitive dependency that pins it to 4.4.0 which would be surprising I guess.

The problem with just yanking the release is that it actually solves #394 which was an issue for some other users.

[fschulze]

It is using 4.3.0 which is broken for Python 3.7 on Windows, because the fix is in 4.4.0 which removed Python 3.7. So it would be nice to yank 4.3.0.

[malthe]

@fschulze done!

[malthe]

@fschulze 4.4.2 should work on Windows – but it does still require Python 3.8+.