Skip to content
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

Merged
merged 53 commits into from
Oct 9, 2024

Conversation

casparvl
Copy link
Collaborator

@casparvl casparvl commented Sep 4, 2024

This no longer depends on #185
We can add the logging of the version back in as a part of #185

Copy link
Collaborator

@smoors smoors left a 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!

Comment on lines 16 to 18
# 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?
Copy link
Collaborator

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

Comment on lines 7 to 9
# 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
Copy link
Collaborator

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.

Copy link
Collaborator

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

Comment on lines 17 to 20
scale = parameter(SCALES.keys())
valid_prog_environs = ['default']
valid_systems = ['*']
time_limit = '30m'
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Caspar van Leeuwen added 5 commits September 19, 2024 12:13
…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
@casparvl
Copy link
Collaborator Author

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

pip install git+https://github.com/casparvl/test-suite.git@use_mixin_class

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?

@casparvl
Copy link
Collaborator Author

I was being silly. The use_mixin_class is a branch on my fork. Tags are not forked, and thus my fork did not contain any tags.

I now added a tag v0.3.3 to the latest commit in my use_mixin_class branch. Then:

(my_test_venv) [casparl@tcn1 test-suite]$ pip install git+https://github.com/casparvl/test-suite.git@use_mixin_class
Collecting git+https://github.com/casparvl/test-suite.git@use_mixin_class
  Cloning https://github.com/casparvl/test-suite.git (to revision use_mixin_class) to /tmp/pip-req-build-g9hmxril
  Running command git clone -q https://github.com/casparvl/test-suite.git /tmp/pip-req-build-g9hmxril
  Running command git checkout -b use_mixin_class --track origin/use_mixin_class
  Switched to a new branch 'use_mixin_class'
  branch 'use_mixin_class' set up to track 'origin/use_mixin_class'.
  Resolved https://github.com/casparvl/test-suite.git to commit 97e60abb37126bb7165ec66197459f0b08320f88
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: eessi-testsuite
  Building wheel for eessi-testsuite (PEP 517) ... done
  Created wheel for eessi-testsuite: filename=eessi_testsuite-0.3.3-py3-none-any.whl size=1854649 sha256=ff462274cc8995e5e592378f90a0c05c65a26dbbc7f441da9a0ea373d11ee0de
  Stored in directory: /tmp/pip-ephem-wheel-cache-k8t31ry2/wheels/65/6f/b7/6fb6ee1323b931899a049e67caaadafd3ee34eb1b811ca39ae
Successfully built eessi-testsuite
Installing collected packages: eessi-testsuite
Successfully installed eessi-testsuite-0.3.3

As expected.

@casparvl
Copy link
Collaborator Author

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:

$ python setup.py sdist
...
$ ls -al dist/eessi-testsuite-0.3.3.tar.gz
-rw-r----- 1 casparl casparl 1844717 Sep 20 16:34 dist/eessi-testsuite-0.3.3.tar.gz

Awesome, I think that automatic versioning is working perfectly fine!

@casparvl
Copy link
Collaborator Author

Oh, we should probably list setuptools_scm as an (optional?) dependency somewhere, since that will be needed to retreive the version at runtime.

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 setuptools_scm to do the runtime version check.

@boegel
Copy link
Contributor

boegel commented Sep 20, 2024

Oh, we should probably list setuptools_scm as an (optional?) dependency somewhere, since that will be needed to retreive the version at runtime.

I have some bad experiences with setuptools_scm, if we can avoid it I would stay away from it tbh...

Unless it's a huge win somehow and makes our lives a lot easier.
It may seem to be working out fine, but I've seen it act up once too many times to "trust" it.

Then again, maybe I cry too easily when managing packages... ;)

@casparvl
Copy link
Collaborator Author

casparvl commented Sep 20, 2024

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 setuptools_scm to setup.py, because we require logic, as versions will depend on the python version. There is no single version that works for all.

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 python -m build, or a pip install . in my own checkout, the version is completely correct.

Caspar van Leeuwen added 2 commits September 21, 2024 10:54
…. The current PR now depends on this, as it relies on the eessi/testsuite/__init__.py file to provide a version
@casparvl
Copy link
Collaborator Author

I've split of the whole setuptools_scm versioning logic into a separate PR #185

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.

@casparvl casparvl marked this pull request as ready for review October 9, 2024 09:44
@smoors smoors changed the title WIP: Try to use mixin class to replace mandatory hooks Add mixin class to replace mandatory hooks Oct 9, 2024
Copy link
Collaborator

@smoors smoors left a 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!

@smoors smoors merged commit 548e9b3 into EESSI:main Oct 9, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants