Test infrasctructure

[marimeireles]

Testing infrastructure:

• We need to figure out what’s the release system is going to be, to define how to support multiple versions
• How many versions back do we want to offer support for the examples?
• If the versions are hosted in pyscript.net we can just rewrite the files and test the same files multiple times (as we’re doing right now with bash in the core repo)
• New examples will add new dependencies, we need to ask the users to add these to an environment.yml file that we use to build the test env in our CI

[pauleveritt]

Some updates on this from the PSC proof-of-concept...

1. Release system. It uses Hypermodern cookiecutter which has a GitHub Action that does releases. But this implies somebody has a PyPI account for PyScript.
2. Supported versions. My position: the "Gallery" is a web app that targets/bundles a version. The examples therefore need to pass tests for the current bundled version, no more, no less.
3. Rewrite. Shouldn't be a problem. At the moment, each example gets a py-config dictated by the Jinja2 layout template. (With a caveat that isn't material.)
4. Build environment. This is an important and open point, as is the CI part. At the moment, the PSC prototype is using GitHub Actions as the "build" environment. @marimeireles is that ok?
5. Dependencies. This is an interesting one. We'll need to document it. The challenge comes from examples that imply an app server backend. We'll have no real way of hosting those, at least at first. We'll have to put those in a different pile.