-
Notifications
You must be signed in to change notification settings - Fork 70
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 packaging to matl sell policy #1749
Conversation
Downstream Build Status Report - 6144905 - 2024-05-28 08:59:12 -0600Build
|
Pull Request Test Coverage Report for Build 9271705192Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some first thoughts...
Signed-off-by: Katie Mummah <katiemummah@gmail.com>
Ok unfortunately pulling this one back into drafts because as I'm developing it with cycamore#603 something odd is happening. It seems like everything is working well, but then when I try to run a toy test input, like the one here, the simulation aborts... because it can't find any packages. However, this appears to happen after the package is already found once successfully. I've so far identified that I'm a bit at a loss here... More digging is definitely needed, it might be the case that I'm missing something in the setup of packages because I'm just not that familiar with the process of spinning up a full simulation |
Ok, I think I understand:
I'm going to fix this by allowing, but not requiring, packages to be created with a But instead of creating dummy packages, I think I'm just going to create the package again? If this is controversial, happy to consider another option, but I don't think we need dummy packages in the same way that dummy compositions are useful. New workflow
|
…e new line added before change occurs)
Why isn't this an issue for recipes? Is it because they don't have IDs? I wonder if we should plan to remove the IDs in the future (outside of PhD scope)? |
Actually... how hard would it be to remove the concept of |
Probably not that hard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Now that we've changed to package name, I noticed that it's still a little different from how we use recipes: we store the Composition::Ptr
for each recipe, rather than the name. I'll make an issue to review this for packages too.
Material sell policy can be initialized with a package type. When responding to requests, checks against packaging restrictions. When returning trades, packages material popped from buffer.