Limit the use of EverestConfig in function signatures in everest csv exporting

[DanSava]

Issue
Resolves #9162

• PR title captures the intent of the changes, and is fitting for release notes.
• Added appropriate release note label
• Commit history is consistent and clean, in line with the contribution guidelines.
• Make sure unit tests pass locally after every commit (git rebase -i main --exec 'pytest tests/ert/unit_tests -n logical -m "not integration_test"')

When applicable

• When there are user facing changes: Updated documentation
• New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
• Large PR: Prepare changes in small commits for more convenient review
• Bug fix: Add regression test for the bug
• Bug fix: Create Backport PR to latest release

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.74%. Comparing base (4b18368) to head (5bf883f).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9163      +/-   ##
==========================================
- Coverage   90.76%   90.74%   -0.03%     
==========================================
  Files         351      351              
  Lines       21901    21903       +2     
==========================================
- Hits        19879    19876       -3     
- Misses       2022     2027       +5     

Flag	Coverage Δ
cli-tests	39.24% <ø> (+<0.01%)	⬆️
gui-tests	71.74% <ø> (-0.01%)	⬇️
performance-tests	49.39% <ø> (+<0.01%)	⬆️
unit-tests	79.64% <ø> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yngve-sk]

The refactor in itself looks good but I have some things I'm not totally sure about. For the validation you got rid of the direct everest config and this is nice, and using only batches and keywords from self.

For the export_data, if I understood correctly, this cannot be put within the export config, because the export config may be null even if you want to export, but if you make this a staticmethod of ExportConfig (or keep it in its original place). I also think if you make model.data_file and .output_dir explicit arguments you can drop having to reference an EverestConfig as is done through the self reference there.

I'm not sure if I see why the export logic should be partially moved to the config? They still refer to some stuff under export.py, and the pattern leans towards making it easy to suddenly get circular imports, so if they are to be moved to the configs I'd at least say do it fully and get rid the entire export.py file, or keep it there. In ERT we do have some logic in the configs (maybe too much) but it sort of makes sense to keep the exporting logic in the export config. Would try to get it all into the ExportConfig and make the things that should run without an instance a @staticmethod

[DanSava]

For the export_data, if I understood correctly, this cannot be put within the export config, because the export config may be null even if you want to export, but if you make this a staticmethod of ExportConfig (or keep it in its original place). I also think if you make model.data_file and .output_dir explicit arguments you can drop having to reference an EverestConfig as is done through the self reference there.

I'm not sure if I see why the export logic should be partially moved to the config? They still refer to some stuff under export.py, and the pattern leans towards making it easy to suddenly get circular imports, so if they are to be moved to the configs I'd at least say do it fully and get rid the entire export.py file, or keep it there. In ERT we do have some logic in the configs (maybe too much) but it sort of makes sense to keep the exporting logic in the export config. Would try to get it all into the ExportConfig and make the things that should run without an instance a @staticmethod

I see your point I will just move it back to export.py and make the args explicit.

[yngve-sk]

Nice! Behavior is the same and the logic is more clear 🚀