-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add mixin class to replace mandatory hooks #177
Conversation
…bles that are needed for those hooks are defined in time, and if not, print a clear message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks a lot for this initial effort toward a mixin class, and for identifying possible issues!
eessi/testsuite/eessi_mixin.py
Outdated
# Note that I don't think we can do anything about the things set in the class body, such as the parameter's. | ||
# Maybe we can move those to an __init__ step of the Mixin, even though that is not typically how ReFrame does it anymore? | ||
# That way, the child class could define it as class variables, and the parent can use it in its __init__ method? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it's unfortunate that there is no support for @run_before('init')
methods
eessi/testsuite/eessi_mixin.py
Outdated
# Hooks from the Mixin class seem to be executed _before_ those of the child class | ||
# Thus, if the Mixin class needs self.X to be defined in after setup, the child class would have to define it before setup | ||
# That's a disadvantage and might not always be possible - let's see how far we get |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if self.X needs to be defined after setup in the child class, the mixin class can still use it in a @run_before('run')
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another option is to use @run_after('setup', always_last=True)
in the child class which, according to the docs, will ensure those methods will always execute last
https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#pipeline-hooks
scale = parameter(SCALES.keys()) | ||
valid_prog_environs = ['default'] | ||
valid_systems = ['*'] | ||
time_limit = '30m' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can all go into the mixin class, right? those seem ok default values, which the child can still override if needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just tried to move that, but it doesn't work for valid_prog_environs
, valid_systems
and time_limit
. I'm getting
WARNING: skipping test file '/gpfs/home4/casparl/EESSI/test-suite/eessi/testsuite/tests/apps/lammps/lammps.py': reframe syntax error: 'time_limit' already defined in class 'EESSI_LAMMPS_base' (rerun with '-v' for more information)
even though I did remove them from the lammp class itself.
…e dynamic version determined at runtime and store it as a variable in the eessi_mixin class, so it ends up in all tests that are run. This way, you can alwyas see from the run report of reframe which EESSI test-suite version was used
…stalled, try to get it from the git tree
Hm, I went down the rabbit hole of not trying to use hardcoded versions. And then also being able to use them at runtime. It works well from a git checkout. However if I
The version that is used for some reason is 0.1.dev753+g97e60ab. Although I'm not sure how it is supposed to get any other version: for git, it can check the tags and increment by one. Where should it get it's version (or previous version) if you pip-install out of the blue? |
I was being silly. The I now added a tag
As expected. |
I've also followed the steps for release documented in our own readme, to see if that would also give us the right versioning. It does:
Awesome, I think that automatic versioning is working perfectly fine! |
Oh, we should probably list Maybe as an improvement, I should also configure our setup procedure to create a version file, and read from there at runtime as the first option. At least when it is an installed package, that should work. If it's just a git clone, one would still need |
I have some bad experiences with Unless it's a huge win somehow and makes our lives a lot easier. Then again, maybe I cry too easily when managing packages... ;) |
…t, we're probably in a git-cloned repo, and we resort to using setuptools_scm at runtime to determine the version
…tsuite/__init__.py
…rsion below 8 to stay compatible with python 3.6. Once we don't care about 3.6 compatibility anymore, we can upgrade to setuptools_scm and use version_file instead of write_to
Ok, it is a bit silly, since the problem I have been fixing is that we can build the distribution on all python versions in our CI. I don't think that's super important, we really want to be able to install on all version in our CI. Anyway, it works everywhere now. It required pushing the requirement for Note that the only thing that is weird is that the version in the CI always seems to be 0.1-dev1. But that's probably due to how things are done in the CI - if I do a |
…. The current PR now depends on this, as it relies on the eessi/testsuite/__init__.py file to provide a version
I've split of the whole I'd like to get that one merged for the new release (0.3.3). This mixin class will probably take more time, and I don't want to wait with releasing 0.3.3 for this to be finished. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
works like a charm, this will help a lot getting more people to write testing!
This no longer depends on #185
We can add the logging of the version back in as a part of #185