Lua 모듈
더 많은 작업
많은 위키가 틀의 논리를 Lua로 관리하며, Wikven은 빌드 시점에 진짜 MediaWiki를 실행하므로 모듈도 늘 그렇듯 작동합니다. 모듈을 호출한 문서는 모듈의 답이 이미 담긴 상태로 기록되고, 모듈 자체는 게시된 사이트의 문서가 되지 않습니다. MediaWiki에서 Lua는 Scribunto이며, MediaWiki에 함께 들어 있습니다.
두 제품 다 Lua를 렌더링하지만, 아무것도 요구하지 않는 쪽은 Docker 이미지뿐입니다. 단독 실행 바이너리는 arm64에서 인터프리터를 하나 설치해주기를 바랍니다. 아래 표에 세 경우가 있습니다. Lua를 렌더링할 수 없는 빌드는 {{#invoke:}}가 그대로 보이는 문서를 게시하는 대신 중단하고 그 사실을 말합니다.
켜기
.wikven.yaml 파일에 이름을 적으면 그것으로 끝입니다. Scribunto는 MediaWiki에 함께 들어 있으므로 WikvenRepositories 항목이 필요 없고, 대부분의 빌드에서는 엔진도 설정할 것이 없습니다.
extensions:
- Scribunto
모듈 작성하기
모듈은 콘텐츠이므로 다른 문서와 나란히 소스 트리에 놓입니다. 파일에는 .wikitext 표시를 붙이지 않는데, Module: 문서의 콘텐츠 모델은 위키텍스트가 아니라 Lua이기 때문입니다:
src/
Module/
Example
Home.wikitext
Module/Example.wikitext라는 이름도 가져오기는 하지만, 표시 없는 이름이 관례이며 Wikven이 어떤 문서가 어느 파일에서 왔는지 되짚을 때 쓰는 이름도 그것입니다.
확장자가 없는 이름은 편집기에게 아무 단서도 주지 않아서, 파일에 색이 입혀지지도 Lua 관련 기능이 뜨지도 않습니다. 어느 편집기든 확장자 대신 이름으로 한 번 알려주면 됩니다:
.vscode/settings.json이나 사용자 설정에:
{
"files.associations": {
"**/Module/*": "lua"
}
}
소스 옆의 .helix/languages.toml이나 ~/.config/helix/languages.toml에:
[[language]]
name = "lua"
file-types = [{ glob = "**/Module/*" }]
~/.vim/filetype.vim이나 vimrc가 읽어들이는 아무 곳에:
autocmd BufRead,BufNewFile */Module/* setfiletype lua
반대 방향도 됩니다. Module/Example.lua라는 파일도 가져와지는데, 표시자는 제목이 그러지 않으면 위키텍스트가 되는 곳에서만 필요하기 때문입니다. 다만 이름은 그대로 유지되므로 문서가 Module:Example.lua가 되고, 모든 {{#invoke:}}가 그렇게 적어줘야 합니다.
모듈은 평범한 Lua입니다. 아래는 이 사이트가 실제로 가진 모듈 전체입니다:
local p = {}
function p.thisPage( frame )
return '<code>' .. mw.title.getCurrentTitle().text .. '</code>'
end
return p
그리고 문서는 평범한 방식으로 호출합니다:
{{#invoke:Example|thisPage}}
지금 읽고 있는 이 문서에서 실행된 결과는 이렇습니다:
Lua modules/ko
호출문은 <translate> 태그 밖에 있습니다. 모듈의 반환값은 번역 단위가 아니기 때문입니다. 어떤 언어의 독자에게든 모듈이 쓴 그대로 전달되므로, 말은 모듈이 아니라 그것을 감싼 문장이 담당해야 합니다.
게시된 사이트에 남는 것
모듈의 출력뿐입니다. Module:은 콘텐츠 이름공간이 아니므로 모듈은 결코 문서로 내보내지지 않고 Lua 소스도 게시되지 않습니다. 독자가 받는 것은 그 답이 이미 담긴 문서입니다. 독자의 브라우저에서는 아무것도 실행되지 않는데, 실행될 것이 남아 있지 않기 때문입니다. 모듈은 빌드 시점에 한 번 실행되었습니다.
모듈에 무엇을 담을지 정할 때 알아둘 만한 점입니다. 모듈이 위키 자체의 내용에서 계산해 내는 것, 다른 문서들에서 모은 표나 정렬된 목록이나 연속물 안에서 그 문서가 놓인 순서 같은 것은 한 번 계산되어 고정됩니다. 독자의 시계나 질의처럼 읽는 시점에 필요한 것은 실행될 곳이 없습니다.
어느 제품이 렌더링하나
Scribunto에는 엔진이 둘 있고, 어느 쪽을 쓸지는 스스로 고릅니다. 하나는 PHP 확장인 luasandbox이고, 다른 하나는 외부 lua 프로그램을 실행하며 따로 지정된 것이 없으면 Scribunto가 자기 소스 트리에 들고 다니는 인터프리터로 떨어집니다. 어느 쪽이 될지는 제품에 달렸고, 세 가지 조합 중 여러분에게 무언가를 요구하는 것은 하나뿐입니다.
| 제품 | 엔진 | 설정할 것 |
|---|---|---|
| Docker 이미지 | PHP에 컴파일해 넣은 luasandbox |
없음 |
| 단독 실행 바이너리, x86-64 | Scribunto가 들고 다니는 인터프리터 | 없음 |
| 단독 실행 바이너리, arm64 | 여러분이 설치한 인터프리터 | 아래의 luaPath
|
arm64 줄은 wikven의 한계가 아닙니다. Scribunto에는 내놓을 arm64용 인터프리터가 없습니다. 번들된 다섯 개는 전부 인텔용이며 — Linux와 Windows가 32비트와 64비트로 둘씩, macOS가 64비트 하나입니다 — 그중에서 운영체제와 정수 크기로 고르기 때문에 arm64에서는 x86-64 Linux용을 집고, 그것은 시작하지 못합니다. Lua 5.1을 설치하고 — 데비안과 우분투에서는 apt install lua5.1이며, Lua 5.1인 LuaJIT도 됩니다 — 그 경로를 적어주십시오:
extensions:
- Scribunto
config:
ScribuntoEngineConf:
luastandalone:
luaPath: /usr/bin/lua5.1
이 설정은 모든 제품에서 읽히므로, 이것을 담은 소스 트리는 어디서나 똑같이 빌드됩니다.
빌드와 사이트가 어긋날 때
여기서 어긋날 수 있는 것은 둘이고, 어느 쪽인지는 사이트가 무엇을 요구했는지가 가릅니다. 사이트가 요구했는데 이 빌드가 줄 수 없는 Lua는 빌드를 끝내고, 사이트가 요구한 적 없는 Lua는 알리기만 하며 베이크는 계속됩니다.
Scribunto 없는 모듈. Module: 파일이 있는데 extensions에 Scribunto가 없는 소스 트리도 빌드되며, 그 파일들이 무엇이 되는지를 알려줍니다. {{#invoke:}}는 문서에 자기 소스 텍스트로 남고, .wikitext 표시를 붙인 모듈은 문서로 게시됩니다. 여러분의 Lua가 세상에 읽히도록 내보내지는 것입니다. 빌드는 대신 결정하지 않고 본 것을 말하는데, Module: 파일이라는 판단은 이름에서 읽어낸 짐작이고 그 파일은 들어오는 중일 수도, 나가는 중일 수도, 다른 용도로 두고 있는 것일 수도 있기 때문입니다.
Wikven: the source has 1 Lua module file(s) (Module:Example) and Scribunto is not in
extensions, so a {{#invoke:}} is left in the page as its own source text, and a module
named with the .wikitext marker is exported as a page. Add Scribunto to extensions if
those modules are meant to run.
엔진 없는 Scribunto. Scribunto를 나열한 사이트는 그것을 실행할 것이 아무것도 없는 곳에서 거부됩니다. 실제로는 luaPath를 지정하지 않은 arm64의 바이너리가 그렇습니다. 이쪽은 알리는 데 그치지 않고 거부되는데, 사이트가 Lua를 분명하게 요구했고 이 빌드는 그것을 줄 수 없기 때문입니다. 엔진은 찾아보는 데 그치지 않고 실제로 실행해봅니다. arm64에서 Scribunto가 골랐을 인터프리터는 존재하고 실행 표시도 붙어 있으면서 시작하지 못하는데, 실행해보는 것 말고는 그 차이를 알 방법이 없기 때문입니다.
Wikven: this site lists Scribunto and no Lua engine is available here. The Docker image
compiles luasandbox into its PHP. The standalone binary carries no engine of its own and
falls back to the lua interpreter Scribunto ships, which is built for 64-bit x86 Linux and
did not run here. Install a Lua 5.1 interpreter and name it under
ScribuntoEngineConf.luastandalone.luaPath, bake this site with the Docker image, or drop
Scribunto from extensions and the Module: pages with it.
그 거부는 말뿐 아니라 종료 코드에도 담기므로, 굽고 나서 배포하는 스크립트는 아무것도 없는 것을 올리는 대신 멈춥니다. 위의 알림은 알림에 그칩니다. 그것을 출력한 베이크도 다른 베이크처럼 0으로 끝나며, 방금 설명한 그대로의 사이트를 씁니다.
이 문서 사이트도 모듈을 하나 쓰며, 지금 읽고 계신 이 문서는 바뀔 때마다 이미지로 구워지고 모듈의 답이 그 안에 있는지 확인됩니다. 바이너리도 자기 소스 트리로 같은 규칙을 적용받는데, x86-64는 바뀔 때마다 arm64는 나이틀리마다입니다. 그러니 위 표의 각 줄은 이 문서의 주장이 아니라 기계가 확인하는 것입니다.