Source Owned Workspace

패키지 이름과 import를 한 곳에 적기

Gooo 소스에는 이미 package app, import diagnostics "tools/diagnostics"처럼 이름과 가져올 패키지가 적혀 있습니다. 작업공간 파일에도 같은 내용을 다시 적으면 함수를 가져다 쓰거나 파일을 옮길 때 맞춰 고칠 곳이 늘어납니다.

PR 1381을 개발 브랜치 d3552fa2에 병합했습니다. 작업공간의 name과 imports를 생략하면 Gooo 파일에서 읽습니다. 실제 파일의 위치와 실행할 함수는 작업공간에서 지정합니다. 새 형식은 공개 0.6.11 개발판에서 사용할 수 있습니다. 필수 CI 여섯 개와 원본 검증 기록을 확인했고, 검사한 소스와 병합 결과의 파일 트리가 같습니다. 병합 근거와 원본. 0.6.11 준비 PR 1382를 병합하고 네 플랫폼 배포 검사를 통과했습니다. 공개 macOS 파일을 설치해 표준 라이브러리와 자체 모델의 기존 입력·부분 결과·재실행도 확인했습니다. 배포와 실제 사용 원본.

작업공간에 남기는 내용

세 패키지를 쓰는 진단 도구는 다음처럼 적을 수 있습니다.

{
  "schema": "gooo/package-workspace-manifest/v1",
  "entry": {"package_path": "app/explain", "activity": "Main"},
  "packages": [
    {"path": "app/explain", "sources": ["app.gooo.fixture"]},
    {"path": "tools/diagnostics", "sources": ["diagnostics.gooo.fixture"]},
    {"path": "tools/rules", "sources": ["rules.gooo.fixture"]}
  ]
}

각 파일의 package 선언에서 이름을 읽고, import를 모아 의존 관계를 만듭니다. 한 패키지에 파일이 여러 개면 이름이 일치하는지 확인하고 가져오기는 합칩니다. app/explain이라는 위치와 app이라는 소스 이름도 각각의 역할대로 유지합니다.

이름이나 import 목록을 직접 적으면 소스와 대조합니다. 특히 imports: []는 가져오기가 없다는 명시적 값입니다. 생략하면 소스에서 읽는다는 점을 구분합니다. 기존에 작업공간에만 의존 관계를 적던 프로그램도 계속 읽습니다.

전체 예제와 실행 명령.

조립한 프로그램을 계속 쓸 수 있나

같은 읽기 경로를 패키지 확인, 실제 실행, 저장 재실행, 남은 조립 이어가기와 Gooo 조립 정책에도 연결했습니다. 새 라이브러리·진단 프로젝트 템플릿도 짧은 구성을 만듭니다. 기존 명시형과 새 형식으로 해석한 전체 패키지 그래프가 같고, 원래 작업공간 파일의 지문은 각각 보관하는 것을 검사했습니다.

실제 가져온 함수 호출, 폴더 이동 후 저장 재실행, Gooo 정책이 부분 결과를 받아 남은 후보를 조립하는 검사도 통과했습니다. 잘못된 패키지 이름, 없는 의존 패키지와 순환 관계는 오류로 남깁니다.

공개 라이브러리로 사용한 결과

표준 라이브러리의 소스를 그대로 가져와 작업공간의 반복 메타데이터만 뺀 뒤 자체 그래프 모델을 연결했습니다. 고정 순서와 모델 모두 기존 열 입력을 맞혔고, 생성 프로그램과 실제 값은 명시형 구성과 같았습니다. 두 방식 모두 후보 여덟 개가 필요했습니다. 저장 재실행에서도 새 추론 없이 같은 결과를 얻었고 입력만 준 세 건은 정답률을 붙이지 않고 실제 값을 반환했습니다.

이 결과는 기존 프로그램으로 컴파일러 변경을 확인한 회귀 관측입니다. 함수와 선택지, 평가 입력, 모델 가중치는 바꾸지 않았습니다. 계획·검사·자체 모델 실행 원본.