Skip to content

Make module binding look in Main - #27

Merged
tuckermcclure merged 1 commit into
mainfrom
tucker/look-for-unknown-modules-in-main
Jun 26, 2026
Merged

tuckermcclure merged 1 commit into
mainfrom
tucker/look-for-unknown-modules-in-main

Conversation

@tuckermcclure

Copy link
Copy Markdown
Member

Summary

Fix base_module round-tripping for values whose type is defined in an external root module, such as Dates.Date.

Previously, write_to_yaml(...; base_module = C) could emit a type tag like Dates.Date, but load_from_yaml(...; base_module = C) only tried to resolve Dates inside C, causing load to fail unless C.Dates existed.

This updates name resolution so that:

  • Names are still resolved relative to base_module first.
  • Explicit roots Main, Base, and Core continue to work.
  • If the first name is not defined in base_module, the loader can resolve a matching module binding from Main, covering tags like Dates.Date.
  • Resolution now uses isdefined before getfield instead of relying on try/catch.

I also updated the README to document the base_module/Main import contract and added a regression test for Dates.Date.

Testing

Added a unit test that failed before making the changes and that works now.

@tuckermcclure
tuckermcclure merged commit 02333f6 into main Jun 26, 2026
6 checks passed
@tuckermcclure
tuckermcclure deleted the tucker/look-for-unknown-modules-in-main branch June 26, 2026 16:39
@tuckermcclure
tuckermcclure restored the tucker/look-for-unknown-modules-in-main branch June 26, 2026 16:53
@tuckermcclure
tuckermcclure deleted the tucker/look-for-unknown-modules-in-main branch June 26, 2026 17:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants