Instancer : Support relative prototype paths #6248
Open
+652
−73
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
danieldresser-ie
force-pushed
the
instRelRoots
branch
from
7ec227b to
8f5a6a9
Compare
We still catch these invalid prototype paths, but we do it slightly deeper in the hierarchy
danieldresser-ie
force-pushed
the
instRelRoots
branch
from
8f5a6a9 to
18b28a8
Compare
…NCER_EXPLICITABSOLUTEPATHS
danieldresser-ie
force-pushed
the
instRelRoots
branch
from
18b28a8 to
5decadc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm deleting the previous discussion here, and starting over, because this is a completely different PR to the first time around.
It is now built on top of #6258, #6272, and #6271, ( in addition to requiring the cortex change ImageEngine/cortex#1451 ). Assuming you want to review this in one go, those other PRs can be closed.
I'm feeling fairly good about this - seems to do what we want, with fairly decent test coverage. This includes performance tests - the one noticeable regression is testPrototypeHashPerf, which went from 0.02s to 0.13s. This test was written specifically to demonstrate worst case behaviour - in practice, we usually need to actually evaluate capsules, not just hash them, and the gain in consistency and performance from reusing capsules when possible should outweigh the cost of the much more accurate hash.
While I'm feeling fairly good, this is a significant change to some code that interacts in fairly complicated ways, so it does call for careful review. If you have access to production data from the users requesting the feature, it would be great to confirm that it works as desired in practice.
The only thing I know still needs doing is writing changelog entries - since this isn't getting merged this week, I'm expecting to need to do some rebasing, so I'll write changelog entries afterwards.