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 fair2.X to openscm-runner #93

Open
chrisroadmap opened this issue Feb 7, 2024 · 6 comments
Open

Add fair2.X to openscm-runner #93

chrisroadmap opened this issue Feb 7, 2024 · 6 comments

Comments

@chrisroadmap
Copy link
Contributor

The motivation

Add fair2.X (currently v2.1.3) to openscm-runner

The proposed solution

Add a fair or fair2 adapter. This will be trickier than adding a new SCM, since fair already exists at v1.6.2.

There are two options I see, both with pros and cons.

  1. Add a new fair2 adapter alongside fair. Advantages: does not break backward compatibility, existing workflows that rely on fair will still work, and both model versions available for comparison. Disadvantage: not sure if easy (or possible) to include two versions of the same module as dependencies.
  2. Update the existing fair adapter to point to the newest version of fair. Advantages: can be more easily updated, cleaner namespace. Disadvantage: backward incompatibility, will break many existing workflows including the IPCC assessment. Mitigation: pin versions of openscm-runner in projects, though requires communication.

My preferred solution is the second one.

Alternatives

Bypass openscm-runner altogether in workflows. However, several projects use it as a module, and it would be nice to have continually updated calibrations and versions.

@znicholls
Copy link
Collaborator

znicholls commented Feb 7, 2024

There is also option 3: make your FaIR adapter flexible. Basically, you would want some logic in your adapter (and we can talk about how exactly if you want to go to this route) so that the user just asks for FaIR, but what they receive back depends on which FaIR version is installed (if FaIR 1.6.2 is installed, they get back the current adapter, if FaIR 2+ is installed, they get back the FaIR2 adapter). That would maintain a single interface (at least from the high-level user's view) but you can support both versions in the same openscm-runner release.

For what it's worth, we may do option 3 with MAGICC8 (although maybe not, as MAGICC8 will probably look and feel completely different from MAGICC7).

@znicholls
Copy link
Collaborator

znicholls commented Feb 7, 2024

Disadvantage: not sure if easy (or possible) to include two versions of the same module as dependencies.

I mean you obviously can't have two versions of FaIR installed at once, but you can just make the dependency pin something like "fair >=1.6.2" (so users can install 2+ if they want and then your adapter just figures it out at run time). If you need to be more specific than that, maybe you can list compatible versions e.g. "fair == 1.6.2, 2.0.3, 2.1.2" (I'm not sure if you need that or it is supported by pip, but maybe it is...)

@chrisroadmap
Copy link
Contributor Author

Something like this could work

version = fair.__version__
logger.info(f'running with installed fair v{version}')
if version[:3]=='1.6':
    # do current adapter
elif version[:3]=='2.1':
    # do new version
else:
    raise SomeException(f'version {version} of fair not currently supported. Please consider updating your environment')

@znicholls
Copy link
Collaborator

Ye exactly

@chrisroadmap
Copy link
Contributor Author

I prefer my original option 2 since keeping two versions is causing me bookkeeping headaches and it's difficult to test that the old version doesn't break - or at least I'm not smart enough to figure this out in poetry - while developing the new.

@znicholls
Copy link
Collaborator

Ye you'll probably need two virtual environments going at once for that parallel development to work, or add tox or something.

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

No branches or pull requests

2 participants