-
Notifications
You must be signed in to change notification settings - Fork 35
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
comp_id.module #532
comp_id.module #532
Conversation
I put an example of the problem in an issue here: #533 |
I think @rjplevin needs to make the call here. To me it seems fine to store the module itself instead of the name. With the caveat that we should think through what that means if someone redefines a module... Probably it would mean that one would then have a reference to an outdated module around... |
Rich started implementing this differently in his |
@davidanthoff I believe we decided to merge this as is for now. Do you want to take a look before I merge it? The travis tests aren't passing because the models are on the old versions |
Looks good! We should really try to move to a situation where we don't end up with a broken CI build on |
Yes, I'm not sure how to prevent that when we have updates with breaking changes. I think Lisa has a better grasp on what the ideal workflow could be. One thing on this PR before I merge it though: should I rename the field in the |
I'm indifferent. |
@davidanthoff this is for what we were talking about on Friday, to have the
comp_id
in a component definition hold the full module instead of just a symbol of the bottom most module. This currently works now (on the MimiIWG example that wasn't working before) and passes all of the Mimi tests (although I had to change three tests that were specifically testing this functionality).Would it be better though to have the
comp_id
still store a symbol, but just make sure the symbol is the full module path (i.e. make it holdSymbol("Main.foo.bar")
instead of what it would previously store, which was just:bar
)? I'm just not sure what the implications are of passing around the actual module object and if there are any disadvantages of this we should be worried about.