You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Carry the project lessons forward after the module folder is prepared
Inheritance never happened in a real render. Every module in the d365 chain
ended up with only the lessons it had learned itself, and none of the ones the
module before it had passed on.
The copy was made in the renderer, before the render started. The first action
of the render is PrepareRepositories, which deletes the module folder outright
to start it clean - and .memory lives inside that folder. So the file was
copied in, deleted seconds later, and the consolidating call at the end of the
first functionality wrote a fresh one containing only what that module had just
learned.
The copy now happens inside PrepareRepositories, immediately after the wipe it
has to survive. MemoryManager holds the predecessor's folder so it owns both
ends of the copy rather than being handed them.
The unit tests did not catch this because they only ever exercised the two
steps separately: resolving the predecessor, and copying between two folders.
Both were correct in isolation. There is now a test that runs PrepareRepositories
against a folder holding an inherited file and asserts the wipe still happens
and the file is still there afterwards; it fails if the call is removed.
That test is built on SimpleNamespace rather than MagicMock on purpose. A
MagicMock attribute satisfies os.fspath, so a path the test forgot to set turns
into a real directory named after the mock instead of an error - which is how an
earlier version of it quietly created a MagicMock/ tree in the repository root.
0 commit comments