Skip to content

Conversation

@victorusu
Copy link
Contributor

@victorusu victorusu commented Sep 11, 2019

Extend the TMod implementation to add support for modules 3.1.

Fixes #784.

@victorusu victorusu requested review from teojgo and vkarak September 11, 2019 11:29
@victorusu victorusu self-assigned this Sep 11, 2019
@pep8speaks
Copy link

pep8speaks commented Sep 11, 2019

Hello @victorusu, Thank you for updating!

Cheers! There are no PEP8 issues in this Pull Request!Do see the ReFrame Coding Style Guide

Comment last updated at 2019-11-25 21:41:24 UTC

Copy link
Contributor

@vkarak vkarak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that Tmod 3.1 has a completely different output and its basic command is also diverse. I think it would make sense to define a separate modules implementation, named tmod31. For symmetry, we can define tmod32 and make tmod and alias to that.

Address PR remark to split TMod into two classes
Add 'tmod31' as possible supported module
Copy link
Contributor

@vkarak vkarak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that everything in all four implementations (TMod, TMod31, TMod4 and LMod) boils down to three basic differences (correct me if I'm wrong):

  1. modulecmd command (python bindings are got in the same way as soon as you have the modulecmd)
  2. Command to get the version string (version strings are all in . format at least)
  3. How python bindings are executed.

Thus if you abstract only these three things in the base class, which imho, could simply be the standard TModImpl, then the subclasses would have just to override these three functions only. Currently, there is lots of unnecessary code duplication between all the three modules systems.

@vkarak vkarak removed this from the ReFrame Sprint 2019w41 milestone Oct 23, 2019
@codecov-io
Copy link

codecov-io commented Nov 16, 2019

Codecov Report

Merging #935 into master will decrease coverage by 0.3%.
The diff coverage is 15.21%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #935      +/-   ##
=========================================
- Coverage      92%   91.7%   -0.31%     
=========================================
  Files          81      81              
  Lines       11030   11076      +46     
=========================================
+ Hits        10148   10157       +9     
- Misses        882     919      +37
Impacted Files Coverage Δ
reframe/core/modules.py 60.66% <15.21%> (-6.1%) ⬇️
reframe/core/config.py 84.61% <0%> (+1.7%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d7fa1be...f9ab9ab. Read the comment docs.

Copy link
Contributor

@vkarak vkarak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will merge this as soon as you update the documentation. It's not exactly what I want, because the code duplication is not addressed, but I will merge it since it has been standing for long time. I will open a follow up issue on refactoring the modules backend implementation. See #1063.

@vkarak vkarak added this to the ReFrame sprint 2019w46 milestone Nov 25, 2019
@vkarak vkarak merged commit 4d669a0 into reframe-hpc:master Nov 25, 2019
@victorusu victorusu deleted the feature/modules3_1 branch October 6, 2020 19:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support for modules version 3.1

4 participants