Closed bgyori closed 2 years ago
We were still thinking about this and experimenting. The directory is set up as an sbt project (which doesn't preclude other possibilities) and so the python code would belong in src/main/python and src/test/python. Presently travis is used to run the Scala test code, rather than Github Actions, and it also needs to stay compatible with https://jitpack.io. None of this rules out your suggestion, as far as I know. We have some Scala projects being tested with Github Actions, so if travis and github conflict somehow, travis could be changed.
I'm not familiar with sbt
but Python projects following the typical src/
layout keep their code in src/<package_name>/
and their tests in tests/
(keeping the tests and source separate is smart to make sure that tests don't accidentally import code using absolute imports that should only ever be used in non-packaged code). There's also the alternative where the python package is code in a folder in the top level with the package's name
Since this project is mostly Scala, it would probably be ideal to keep testing under sbt
. However, @kwalcock , I wonder if we can configure the travis commands to call both sbt
and pytest
?
Since this project is mostly Scala, it would probably be ideal to keep testing under
sbt
. However, @kwalcock , I wonder if we can configure the travis commands to call bothsbt
andpytest
?
Yes, this is definitely possible! You can even define a testing matrix for this kind of thing
We can keep using Travis of course, but what I meant with Github Actions for Python tests, specifically, would be set up as an independent test build, not a replacement. When doing a PR, you would see both checks side by side - the existing sbt testing workflow wouldn't have to be modified.
If they manage to work side by side, I don't personally (Mihai gets gets last word here, of course) mind splitting between Travis and Github, especially if it follows the format of at least one of our conventions. Here we have some Python scripts within Eidos and those will probably need to stay more within the sbt framework, and then we would just use the (almost) same process for Ontologies. That's not a straight shot, though, because eidos is being tested on Jenkins right now rather than Travis. If you have some configuration files and accounts that let you copy and paste a solution, that seems cost effective. I saw what you referred to earlier, but was working more toward a Travis solution.
BTW it was @zupon who was wanting to write tests and might have an opinion on pytest vs. nosetests, so I'm tagging him. At a UAz meeting last week, it sounded like pytest was the preference, though.
Re Travis, a while ago we migrated all our testing from Travis to Github because Travis now has a very limited free quota for open source projects and our account quickly hit that limit. Has your group not had issues with this?
Yes, we have. I don't think we've exhausted the overall free quota on any recently, but the individual tests were exceeding time and space limits. Several projects were converted to Jenkins which we have running on a local server. This was AFAIK before github offered an alternative. These ontology tests are tiny, so I was sticking with Travis for now. The Travis configuration would be out of your way if you want to add github tests. Travis might be turned off then.
Referencing #138, I think we should move the Python code into a package, implement some tests with a framework like pytest (or nosetests), and then set up Github Actions to run those tests. @kwalcock if you agree that we should do this, we can page @cthoyt who could do this very quickly.