google
Improve automated tests to cover what people install with `pip install magika`, rather than `poetry` environment.
The current CI does the equivalent of poetry install && pytest tests. This is great to test the current code on github.
However, we currently have no tests for "what people actually install" with pip install magika. The assumption is that the poetry environment / installation is the same as what people get with pip install magika. So far this assumption has hold true (we have no reported issues on this), but I would feel better if we would start automatically testing more closely what's actually installed by users. This feels even more important for platforms we are not so familiar with, e.g., Windows and Mac OS.
Hello @gaby, actually, this one feels more important than testing for test devs installation. do you know what's the best practice? schedule a test of "pip install magika" and a quick test with it on a regular basis?
Merged the docker container instructions and cleaned up. Maybe we could run this as part of some tests: https://github.com/google/magika?tab=readme-ov-file#running-in-docker
Hello @gaby, actually, this one feels more important than testing for test devs installation. do you know what's the best practice? schedule a test of "pip install magika" and a quick test with it on a regular basis?
This should be doable by creating a wheel, installing the wheel and then running the cli against the test data directory and comparing output with expected output.
I have a draft on my VM, can work on it during the weekend.
What I realized is that the cli can't be tested by installing from pypi because that would be installing an already released version.
Oh I see what you are saying.
In my mind, I was actually thinking about testing "what's out there", to make sure that things don't break over time (is this something that people do?). And for that I was thinking about docker-based setup.
But yes, what you are saying is also important, testing "the current package that we would release". For this, I suggest to use poetry: to create the package (that we then push to pypi) we do poetry build, and then you get something you can pip install <path>. Maybe we can do all this in the docker: clone the repo, do poetry build, pip install
@reyammer That should work (using poetry build then pip install).
Docker can't be used for this since you ideally want to test this for linux/mac/windows and all supported Python versions.
- Docker Windows images are +5GB each.
- Doxker in MacOS uses qemu emulation inside the container the platform is
arm64/linuxwhich defers from the hostarm64/darwin.