Guide가이드

The mapping manifest매핑 매니페스트

One file says which Python module is which Kotlin package.어떤 파이썬 모듈이 어떤 Kotlin 패키지인지, 파일 하나가 말합니다.

implemented구현

pythonx-map.toml is implemented and tested (tests/test_pythonx_map.py). It lives at pythonx/compose/pythonx-map.toml, inside the package, and ships in the wheel.

pythonx-map.toml 은 구현되어 있고 테스트됩니다 (tests/test_pythonx_map.py). 패키지 안의 pythonx/compose/pythonx-map.toml 에 있으며 wheel 에 함께 담깁니다.

Mapping a module모듈 대응시키기

[modules]
"pythonx.compose.material3" = "androidx.compose.material3"
"pythonx.compose.layout"    = "androidx.compose.foundation.layout"

The second row is why the mapping is written down rather than derived: it drops foundation. from the middle of the name, which no prefix rule can do.

두 번째 줄이 대응을 유도하지 않고 적어 두는 이유입니다: 이름 중간의 foundation. 을 빼는 것은 어떤 접두사 규칙으로도 할 수 없습니다.

Every row is a real file on disk: a new pythonx.compose.* module gets a row here and an __init__.py that calls reexport(__name__), in the same change.

모든 줄은 디스크에 있는 실제 파일입니다: 새 pythonx.compose.* 모듈은 같은 변경 안에서 여기 한 줄과, reexport(__name__) 를 부르는 __init__.py 를 함께 얻습니다.

Allowing a raw number숫자로 쓰기 허용

[value-classes]
raw-primitive-allowed = [
    "androidx.compose.ui.unit.Dp",
]

Only add a value class whose constructor is the identity on its number. Color and TextUnit are deliberately absent, and a test fails if they appear.

생성자가 숫자에 대한 항등인 값 클래스만 추가합니다. Color 와 TextUnit 은 의도적으로 빠져 있으며, 들어가면 테스트가 실패합니다.

Lending a name to another module다른 모듈에 이름 빌려주기

[aliases."pythonx.compose.material3"]
"pythonx.compose.layout" = ["Column", "Row", "Spacer"]

The notebook imports Column, Row and Spacer from material3, while Kotlin declares them in the layout package. This section makes material3 answer for them too. It is data, not a wrapper: the object is the same one either way, and a name not listed is not borrowed.

노트북은 Column, Row, Spacer 를 material3 에서 import 하지만, Kotlin 은 이들을 layout 패키지에 선언합니다. 이 섹션이 material3 도 이 이름들에 답하게 합니다. 래퍼가 아니라 데이터입니다: 어느 쪽에서 가져와도 같은 객체이고, 목록에 없는 이름은 빌려주지 않습니다.

Keeping it in step with the notebook노트북과 맞춰 두기

A test reads every pythonx import in the user's notebook and fails if the manifest does not map it. The notebook lives only in the maintainer's checkout, so elsewhere that test has nothing to check, so run it there before claiming coverage.

테스트 하나가 사용자 노트북의 모든 pythonx import 를 읽고, 매니페스트가 대응시키지 않으면 실패합니다. 노트북은 메인테이너의 체크아웃에만 있으므로 다른 곳에서는 그 테스트가 확인할 것이 없습니다. 커버리지를 주장하기 전에 그곳에서 돌리세요.