Package class and declaration of packages in input file

[nuclearkatie]

• creates Package class
• packages can be declared in input file (optional)

Closes #1654, closes #1655
Part of #1620

[gonuke]

This looks pretty good - I think I found the source of your build error.

[github-actions]

Downstream Build Status Report

Build FROM cyclus_20.04_apt/cyclus

• Cycamore: Success ✅
• Cymetric: Success ✅

Build FROM cyclus_20.04_conda/cyclus

• Cycamore: Success ✅
• Cymetric: Success ✅

Build FROM cyclus_22.04_apt/cyclus

• Cycamore: Success ✅
• Cymetric: Success ✅

Build FROM cyclus_22.04_conda/cyclus

• Cycamore: Success ✅
• Cymetric: Success ✅

[coveralls]

Pull Request Test Coverage Report for Build 7979730040

Details

• -20 of 41 (51.22%) changed or added relevant lines in 4 files are covered.
• 1324 unchanged lines in 45 files lost coverage.
• Overall coverage decreased (-16.7%) to 32.595%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tests/xml_file_loader_tests.cc	3	4	75.0%
src/context.cc	4	7	57.14%
src/package.cc	6	14	42.86%
src/xml_file_loader.cc	8	16	50.0%

Files with Coverage Reduction	New Missed Lines	%
src/any.hpp	1	39.72%
src/bid_portfolio.h	1	59.09%
src/env.h	1	53.85%
src/exchange_solver.cc	1	37.68%
src/exchange_translator.h	1	53.03%
src/greedy_preconditioner.cc	1	50.29%
src/logger.cc	1	68.97%
src/material.cc	1	76.74%
src/query_backend.h	1	81.5%
src/recorder.cc	1	74.32%

Totals
Change from base Build 7027753240:	-16.7%
Covered Lines:	52970
Relevant Lines:	128938

---

💛 - Coveralls

[gonuke]

Another question, but I think this is nearly ready to go...

[gonuke]

• How to manage default? Right now I have the packages managed by context, including creating a default regardless if any are declared in the input file. But, packages isn't context-aware, so when I get around to packaging strategies, not sure how best to call the default value

I think the default will always have id=0 and name=default. You could pick a different default name that is more likely to be unique/rare, but I think it should be easy to access the default package through the context.

[nuclearkatie]

• How to manage default? Right now I have the packages managed by context, including creating a default regardless if any are declared in the input file. But, packages isn't context-aware, so when I get around to packaging strategies, not sure how best to call the default value

I think the default will always have id=0 and name=default. You could pick a different default name that is more likely to be unique/rare, but I think it should be easy to access the default package through the context.

So you think package class should have the context as a member? As written, package doesn't have a way to access the context, because it doesn't have a manager or anything

[gonuke]

• How to manage default? Right now I have the packages managed by context, including creating a default regardless if any are declared in the input file. But, packages isn't context-aware, so when I get around to packaging strategies, not sure how best to call the default value

I think the default will always have id=0 and name=default. You could pick a different default name that is more likely to be unique/rare, but I think it should be easy to access the default package through the context.

So you think package class should have the context as a member? As written, package doesn't have a way to access the context, because it doesn't have a manager or anything

No - I'm not sure the package needs to know about the context. I think a resource will access info about available packages via the context and then store a direct link to their current package. Am I missing something about why/how a package would reference its context?

[nuclearkatie]

• How to manage default? Right now I have the packages managed by context, including creating a default regardless if any are declared in the input file. But, packages isn't context-aware, so when I get around to packaging strategies, not sure how best to call the default value

I think the default will always have id=0 and name=default. You could pick a different default name that is more likely to be unique/rare, but I think it should be easy to access the default package through the context.

So you think package class should have the context as a member? As written, package doesn't have a way to access the context, because it doesn't have a manager or anything

No - I'm not sure the package needs to know about the context. I think a resource will access info about available packages via the context and then store a direct link to their current package. Am I missing something about why/how a package would reference its context?

Ah ok, so the default will always be passed through the resource. I was thinking of having a version of package where no package type was passed, and then the package would have to get access to the default

[gonuke]

• How to manage default? Right now I have the packages managed by context, including creating a default regardless if any are declared in the input file. But, packages isn't context-aware, so when I get around to packaging strategies, not sure how best to call the default value

I think the default will always have id=0 and name=default. You could pick a different default name that is more likely to be unique/rare, but I think it should be easy to access the default package through the context.

So you think package class should have the context as a member? As written, package doesn't have a way to access the context, because it doesn't have a manager or anything

No - I'm not sure the package needs to know about the context. I think a resource will access info about available packages via the context and then store a direct link to their current package. Am I missing something about why/how a package would reference its context?

Ah ok, so the default will always be passed through the resource. I was thinking of having a version of package where no package type was passed, and then the package would have to get access to the default

I think that any time we need to know about a package, we'll have access to the context. I'm not sure I can think of a time when a package needs to know about the context without some other code-context to get the info it needs. If we identify something, we'll have to rethink.

[gonuke]

If you convert from draft, I can merge this

[nuclearkatie]

Looking ahead, resources don't know about the context except when recording, where it is passed to record. So, somewhere is going to need to be context-aware in order to handle the default case. I'll do some more thinking about this...

[gonuke]

This is a great first step on Packaging @nuclearkatie

[gonuke]

Sometime soon, coverage will settle down a little and I'll worry about that test, but I'll go ahead now