Go: 제안: cmd/go: 바이너리에 정적 자산(파일) 포함 지원

embedglob 가 전체 파일 트리를 지원해야 하는지 여부를 고려해 볼 가치가 있습니다. 아마도 일부 Unix 셸에서 지원하는 ** 구문을 사용하는 것 같습니다.

어떤 사람들은 http.FileServer 사용하여 HTTP로 임베디드 자산을 제공하는 기능이 필요합니다.

저는 개인적으로 mjibson/esc(이를 수행함)를 사용하거나 경우에 따라 파일 이름을 변경하여 고유한 경로를 만들고 원래 경로에서 새 경로(예: "/js/bootstrap.min.js": "/js/bootstrap.min.827ccb0eea8a706c4c34a16891f84e7b.js" 로 맵을 추가하는 자체 파일 임베딩 구현을 사용합니다. 그런 다음 href="{{ static_path "/css/bootstrap.min.css" }}" 와 같은 템플릿에서 이 맵을 사용할 수 있습니다.

나는 이것의 결과가 어떤 파일이 프로그램을 빌드하는 데 필요한지 알아내는 것이 중요하지 않을 것이라고 생각합니다.

//go:embed 접근 방식은 또 다른 수준의 복잡성도 도입합니다. 코드를 typecheck하려면 매직 주석을 구문 분석해야 합니다. "포함 패키지" 접근 방식은 정적 분석에 더 친숙합니다.

(여기서 그냥 큰 소리로 생각하고 있습니다.)

@opennota ,

http.FileServer 사용하여 포함된 자산을 HTTP로 제공하는 기능이 필요합니다.

예, 위의 첫 번째 링크는 내가 작성한( 2011년 Go 1 이전) 패키지이며 http.FileServer 사용을 지원합니다. https://godoc.org/perkeep.org/pkg/fileembed#Files.Open

@cepare ,

//go:embed 접근 방식은 또 다른 수준의 복잡성도 도입합니다. 코드를 typecheck하려면 매직 주석을 구문 분석해야 합니다. "포함 패키지" 접근 방식은 정적 분석에 더 친숙합니다.

네, 좋은 지적입니다. 이는 패키지 사용에 대한 매우 강력한 주장입니다. 또한 cmd/go의 문서가 아닌 일반 godoc으로 모든 것을 문서화할 수 있기 때문에 더 읽기 쉽고 문서화 가능합니다.

@bradfitz - https://github.com/golang/go/issues/3035 를 닫으시겠습니까?

@agnivade , 찾아주셔서 감사합니다! 기억하고 있는 줄 알았는데 못 찾겠어요. 지금은 열어두고 다른 사람들이 어떻게 생각하는지 봅시다.

매직 패키지를 사용하는 경우 내보내지 않은 유형 트릭을 사용하여 호출자가 컴파일 시간 상수를 인수로 전달하도록 할 수 있습니다: https://play.golang.org/p/RtHlKjhXcda.

(여기에서 참조된 전략입니다: https://groups.google.com/forum/#!topic/golang-nuts/RDA9Hag8RZw/discussion)

내가 가진 한 가지 관심사는 개별 또는 모든 자산이 너무 커서 메모리에 맞지 않을 수 있는지, 그리고 액세스 시간 대 메모리 풋프린트 또는 일부 중간 구현 중 하나를 선택하기 위한 빌드 태그 또는 파일별 액세스 옵션이 있는지 여부입니다.

내가 그 문제를 해결한 방법은 (물론 내 자신의 구현도 있기 때문입니다 :)) 모든 임베디드 자산을 제공하는 http.FileSystem 구현을 제공하는 것입니다. 그렇게 하면 typechecker를 달래기 위해 매직 주석에 의존하지 않고 http에서 자산을 쉽게 제공할 수 있으며 코드를 변경하지 않고 개발 목적(http.Dir)을 위해 대체 구현을 제공할 수 있으며 최종 구현은 매우 다양합니다. http.FileSystem은 파일 읽기뿐만 아니라 디렉토리 나열에서도 꽤 많은 부분을 다루기 때문입니다.

일반 텍스트 파일을 통해 모든 glob을 지정하는 것이 더 쉬울 수 있지만 여전히 매직 주석이나 무엇이든 삽입해야 하는 것을 지정하는 데 사용할 수 있습니다.

@AlexRouSg 이 제안은 최종 실행 파일에 직접 포함하기에 적합한 파일에만 적용됩니다. 너무 커서 메모리에 맞지 않는 파일에는 이것을 사용하는 것이 적절하지 않습니다. 이 경우를 처리하기 위해 이 도구를 복잡하게 만들 이유가 없습니다. 이 경우 이 도구를 사용하지 마십시오.

@ianlancetaylor , 내 생각에 @AlexRouSg 가 만든 차이점은 파일을 전역 []byte (페이징할 수 없고 잠재적으로 쓰기 가능한 메모리)로 제공하는 것과 Open 를 반환하는 *io.SectionReader Open 호출과 같이 일반적으로 디스크(실행 파일에서)에 있습니다. ( http.File 또는 http.FileSystem 를 cmd/go 또는 런타임에 굽고 싶지 않습니다... net/http는 어댑터를 제공할 수 있습니다.)

@bradfitz 모두 http.File 자체는 http 패키지에 대한 기술적 종속성이 없는 인터페이스입니다. Stat 및 Readdir 메소드 모두 이러한 자산에 매우 유용하기 때문에 모든 Open 메소드가 해당 인터페이스를 준수하는 구현을 제공하는 것이 좋습니다 Stat

@urandom 하지만 "http.File" 이름(https://play.golang.org/p/-r3KjG1Gp-8)을 참조하지 않고는 http.FileSystem을 구현할 수 없습니다.

@robpike 와 저는 몇 년 전(제안 절차가 있기 전) 제안을 통해 이야기를

나는 "압축 대 비"노브의 복잡성에 대해 확신하지 못합니다. 그렇게 하면 사람들은 압축, 압축 수준 등을 제어할 수 있는 기능을 추가하기를 원할 것입니다. 추가해야 할 것은 일반 바이트 파일을 포함하는 기능뿐입니다. 사용자가 해당 파일에 압축된 데이터를 저장하려는 경우 세부 사항은 사용자에게 달려 있으며 Go 측에서는 API가 전혀 필요하지 않습니다.

몇 가지 생각:

• 임베딩을 수행하는 모듈 외부에 파일을 임베드할 수 없어야 합니다. 파일을 생성할 때 파일이 모듈 zip 파일의 일부인지 확인해야 하므로 심볼릭 링크, 대소문자 충돌 등이 없습니다. 합계를 깨지 않고 zip 파일을 생성하는 알고리즘을 변경할 수 없습니다.
• 동일한 디렉토리( //go:embed 주석이 사용되는 경우) 또는 특정 하위 디렉토리( static 가 사용되는 경우)에 임베딩을 제한하는 것이 더 간단하다고 생각합니다. 이렇게 하면 패키지와 포함된 파일 간의 관계를 훨씬 더 쉽게 이해할 수 있습니다.

어느 쪽이든 /etc/shadow 또는 .git 포함을 차단합니다. 둘 다 모듈 zip에 포함될 수 없습니다.

일반적으로 go 명령의 범위를 너무 많이 확장하는 것이 걱정입니다. 그러나 이 문제에 대한 솔루션이 너무 많다는 사실은 아마도 하나의 공식 솔루션이 있어야 한다는 것을 의미합니다.

저는 go_embed_data 및 go-bindata (그 중 몇 가지 포크가 있음)에 익숙하며 이것이 이러한 사용 사례를 다루는 것 같습니다. 다른 사람들이 해결하지 못하는 중요한 문제가 있습니까?

특히 static 또는 embed 디렉토리를 사용하는 경우 특정 파일을 차단하는 것은 그리 어렵지 않습니다. 심볼릭 링크는 그것을 조금 복잡하게 할 수 있지만 현재 모듈 외부에 또는 GOPATH에 있는 경우 디렉토리를 포함하는 패키지 외부에 어떤 것도 포함하지 못하도록 방지할 수 있습니다.

나는 특히 코드로 컴파일되는 주석의 팬은 아니지만 컴파일에 영향을 미치는 의사 패키지도 약간 이상하다는 것을 알았습니다. 디렉토리 접근 방식이 사용되지 않는 경우에는 일종의 embed 최상위 선언을 언어에 실제로 빌드하는 것이 좀 더 합리적일 수 있습니다. import 와 유사하게 작동하지만 로컬 경로만 지원하며 할당할 이름이 필요합니다. 예를 들어,

embed ui "./ui/build"

func main() {
  file, err := ui.Open("version.txt")
  if err != nil {
    panic(err)
  }
  version, err = ioutil.ReadAll(file)
  if err != nil {
    panic(err)
  }
  file.Close()

  log.Printf("UI Version: %s\n", bytes.TrimSpace(version))
  http.ListenAndServe(":8080", http.EmbeddedDir(ui))
}

편집: @jayconrod, 당신이 저를 이겼습니다.

https://github.com/golang/go/issues/35950#issuecomment -561703346에서 확장하려면 노출된 API에 대한 퍼즐이 있습니다. 데이터를 노출하는 확실한 방법은 []byte , string 및 Read -ish 인터페이스입니다.

일반적인 경우는 포함된 데이터를 변경할 수 없도록 하려는 것입니다. 그러나 []byte ( io.Reader , io.SectionReader 등 포함)를 노출하는 모든 인터페이스는 (1) 복사본을 만들거나, (2) 변경성을 허용하거나, (3) []byte 임에도 불구하고 변경할 수 없습니다. 데이터를 string 로 노출하면 이 문제가 해결되지만 포함된 파일을 사용하는 많은 코드는 결국 어떤 식으로든 바이트 슬라이스를 필요로 하기 때문에 결국 복사가 필요한 API 비용이 듭니다.

route (3): []byte 임에도 불구하고 변경할 수 없습니다. 지원 배열에 읽기 전용 기호를 사용하여 이를 저렴하게 시행할 수 있습니다. 또한 []byte 및 string 와 동일한 데이터를 안전하게 노출할 수 있습니다. 데이터를 변경하려는 시도는 실패합니다. 컴파일러는 불변성을 활용할 수 없지만 손실이 크지는 않습니다. 이것은 툴체인 지원이 (내가 아는 한) 기존 codegen 패키지 중 어느 것도 수행하지 못하는 테이블로 가져올 수 있는 것입니다.

(타사 codegen 패키지는 읽기 전용으로 표시된 DATA 기호가 포함된 일반 어셈블리 파일을 생성한 다음 해당 기호를 string 형식으로 노출하는 짧은 아치별 어셈블리 파일을 생성하여 이를 수행할 수 있습니다. s 및 []byte s. 나는 특별히 이 사용 사례를 염두에 두고 CL 163747을 작성했지만, 어떤 codegen 패키지에도 통합하지 못했습니다.)

나는 당신이 불변성 측면에서 무엇을 말하는지 잘 모르겠습니다. io.Reader 이미 불변성을 적용합니다. 이것이 전체 요점입니다. Read(buf) 를 호출하면 _you_가 제공한 버퍼에 데이터를 복사합니다. 변경 buf 즉의 내부에 제로 효과가 후 io.Reader .

@DeedleFake에 동의합니다. 마법 같은 []byte 배열로 게임을 하고 싶지 않습니다. 바이너리에서 사용자 제공 버퍼로 복사하는 것은 괜찮습니다.

여기에 또 다른 주름이 있습니다. DTrace 소스 코드(임베디드)를 사용하는 다른 프로젝트가 있습니다. 이것은 \n과 \r\n의 차이에 민감합니다. (우리는 이것이 DTrace에서 멍청한 일인지 아닌지 논쟁할 수 있습니다. 그것은 요점을 벗어나고 오늘날의 상황입니다.)

백틱 문자열이 소스에 표시되는 방식에 관계없이 둘 다 \n으로 취급하는 것은 매우 유용하며, DTrace를 포함하기 위해 go-generate를 사용하여 이에 의존합니다.

따라서 go 명령에 포함 파일이 추가된 경우 CR/CRLF 처리를 변경하는 옵션이 매우 편리할 수 있다고 부드럽게 제안합니다. 잡았다.

압축과 마찬가지로 "파일 바이트를 바이너리로 복사"에서 멈추고 싶습니다. CR/CRLF 정규화, 유니코드 정규화, gofmt'ing, 다른 곳에 속하는 모든 것. 원하는 정확한 바이트가 포함된 파일을 체크인하십시오. (만약 당신의 버전 관리가 그것들을 그대로 둘 수 없다면, 아마도 gzip으로 압축된 내용을 체크인하고 런타임에 그것들을 gunzip으로 묶을 것입니다.) 우리가 추가하는 것을 상상할 수 있는 _많은_ 개의 파일 뭉치기 노브가 있습니다. 0에서 멈추자.

내가 원하는 만큼 새로운 예약된 디렉토리 이름을 도입하기에는 너무 늦을 수 있습니다.
(2014년에는 너무 늦지 않았지만 지금은 아마 너무 늦었을 것입니다.)
따라서 일종의 옵트인 코멘트가 필요할 수 있습니다.

runtime.Files 유형을 정의한다고 가정합니다. 그러면 다음과 같이 쓰는 것을 상상할 수 있습니다.

//go:embed *.html (or static/* etc)
var files runtime.Files

그런 다음 런타임에 files.Open을 호출하여 데이터와 함께 interface { io.ReadSeeker; io.ReaderAt } 를 반환합니다. var는 내보내지지 않았으므로 한 패키지는 다른 패키지의 포함된 파일을 둘러볼 수 없습니다.

이름은 TBD이지만 메커니즘만큼은 충분해야 하며 더 간단하게 만드는 방법을 모르겠습니다. (물론 단순화도 환영합니다!)

우리가 무엇을 하든 Bazel과 Gazelle도 지원할 수 있어야 합니다. 이는 Gazelle이 주석을 인식하고 globs를 말하는 Bazel 규칙을 작성하도록 한 다음 빌드에 포함할 추가 파일을 생성하기 위해 도구(go 도구 embedgen 또는 무엇이든)를 노출해야 함을 의미합니다(go 명령은 이 작업을 자동으로 수행하고 실제로 추가 파일을 표시하지 않음). 충분히 간단해 보입니다.

다양한 munging이 트릭을 수행하지 못한다면, 그것은 이 새로운 기능을 사용하는 것에 대한 논쟁입니다. 저를 위한 스토퍼가 아닙니다. 이전처럼 go generate를 사용할 수 있지만 새 기능의 이점을 얻을 수 없다는 의미입니다.

일반적으로 munging과 관련하여 누군가가 인터페이스의 구현을 제공하는 솔루션을 상상할 수 있습니다. 파일 자체에서) -- go cmd가 빌드하고 실행하여 포함하기 전에 파일을 사전 필터링합니다. 그런 다음 사람들은 원하는 필터를 제공할 수 있습니다. 어떤 사람들은 dos2unix 구현, 압축 등과 같은 준표준 필터를 제공할 것이라고 생각합니다.

임베디드 프로세서가 무엇이든 간에 모든 빌드 시스템에서 컴파일 가능해야 한다는 가정이 있어야 합니다. 이 목적을 위한 임시 기본 도구를 구축하는 것입니다.

내가 원하는 만큼 새로운 예약된 디렉토리 이름을 도입하기에는 너무 늦을 수 있습니다. [...] 일종의 옵트인 주석이 필요할 수 있습니다.

runtime/embed 와 같은 특수 패키지를 통해서만 파일에 액세스할 수 있는 경우 해당 패키지를 가져오는 것이 옵트인 신호일 수 있습니다.

io.Read 접근 방식은 strings.Contains (예: cmd/go/internal/cfg ) 또는 , 비판적으로 template.Parse .

이러한 사용 사례의 경우 호출자가 전체 blob을 (아마도 메모리 매핑된) string 또는 io.ReaderAt 로 처리할지 여부를 선택하도록 허용하는 것이 이상적입니다.

하지만 이는 일반적인 runtime.Files 접근 방식과 호환되는 것 같습니다. runtime.Files.Open 에서 반환된 것은 메모리 매핑된 표현을 반환하는 ReadString() string 메서드를 가질 수 있습니다.

일종의 옵트인 코멘트가 필요할 수 있습니다.

go.mod 파일의 go 버전으로 이를 수행할 수 있습니다. 1.15 에는 static 하위 디렉토리에 패키지가 포함되고 1.15 이상에는 포함된 자산이 포함됩니다.

(하지만 GOPATH 모드에서는 실제로 도움이 되지 않습니다.)

나는 "압축 대 비"노브의 복잡성에 대해 확신하지 못합니다. 그렇게 하면 사람들은 압축, 압축 수준 등을 제어할 수 있는 기능을 추가하기를 원할 것입니다. 추가해야 할 것은 일반 바이트 파일을 포함하는 기능뿐입니다.

나는 단순함을 위한 추진력을 높이 평가하지만 우리는 또한 우리가 사용자의 요구를 충족시키는지 확인해야 합니다.

https://tech.townsourced.com/post/embedding-static-files-in-go/#comparison에 나열된 도구 14개 중 12개는 압축을 지원하며 이는 상당히 일반적인 요구 사항임을 나타냅니다.

외부에서 사전 빌드 단계로 압축을 수행할 수 있는 것은 사실이지만 여전히 1) 압축을 수행하는 도구가 필요합니다. 2) 일종의 assets.zip 덩어리를 vcs에 확인합니다. 압축을 취소하기 위해 Embed API 주변의 라이브러리. 어느 시점에서 이익이 무엇인지 전혀 불분명합니다.

초기 제안서에 나열된 세 가지 목표는 다음과 같습니다.

• 생성된 파일을 체크인하지 마십시오
• go install / go build 자동으로 임베딩 수행
• 적절한 경우 바이너리로 압축된 자산 저장

이 중 두 번째를 "임베딩을 위한 별도의 도구가 필요하지 않음"으로 읽는다면 압축 파일을 직간접적으로 지원하지 않는 것은 이러한 세 가지 목표를 모두 충족하는 데 실패합니다.

패키지 수준이어야 합니까? 하나의 모듈 = 하나의 프로젝트일 가능성이 높기 때문에 모듈 수준이 더 세분화된 것처럼 보입니다.

이 디렉토리에는 Go 코드†가 포함되어 있지 않으므로 _static 와 같을 수 있습니까?

† 또는 그렇다면 컴파일할 Go 코드 대신 이름이 ".go"로 끝나는 임의의 바이트로 처리됩니다.

만약 그것이 하나의 특별한 디렉토리라면, 로직은 그 디렉토리 트리에 있는 모든 것을 훌쩍 뛰어넘을 수 있습니다. 매직 임베드 패키지를 사용하면 embed.Open("img/logo.svg") 와 같은 작업을 수행하여 자산 트리의 하위 디렉토리에 있는 파일을 열 수 있습니다.

스트링은 충분히 좋은 것 같습니다. []byte 로 쉽게 복사하거나 Reader 로 변환할 수 있습니다. 코드 생성 또는 라이브러리를 사용하여 더 멋진 API를 제공하고 init 동안 작업을 처리할 수 있습니다. 여기에는 압축 해제 또는 http.FileSystem 생성이 포함될 수 있습니다.

Windows에는 자산 포함을 위한 특별한 형식이 없습니다. Windows 실행 파일을 빌드할 때 사용해야 합니까? 그렇다면 제공할 수 있는 작업의 종류에 영향을 미칩니까?

gitfs를 잊지 마세요 😂

• https://github.com/posener/gitfs

예를 들어이 이동 빌드 / 링크의 일부가 될 수없는 이유는 ... 거기에 go build -embed example=./path/example.txt 일부 패키지 그것이 (에 노출하는 액세스 예를 들어 embed.File("example") , 사용하는 대신 go:embed ?

하지만 코드에 스텁이 필요합니다.

@egonelbre go build -embed 문제점은 모든 사용자가 올바르게 사용해야 한다는 것입니다. 이것은 완전히 투명하고 자동적이어야 합니다. 기존 go install 또는 go get 명령은 올바른 작업을 중단할 수 없습니다.

@bradfitz Packr 보다 https://github.com/markbates/pkger 를 추천합니다. 파일 작업을 위해 표준 라이브러리 API를 사용합니다.

func run() error {
    f, err := pkger.Open("/public/index.html")
    if err != nil {
        return err
    }
    defer f.Close()

    info, err := f.Stat()
    if err != nil {
        return err
    }

    fmt.Println("Name: ", info.Name())
    fmt.Println("Size: ", info.Size())
    fmt.Println("Mode: ", info.Mode())
    fmt.Println("ModTime: ", info.ModTime())

    if _, err := io.Copy(os.Stdout, f); err != nil {
        return err
    }
    return nil
}

또는 특정 빌드 태그나 플래그가 대신 런타임에 작업을 수행하도록 대체할 수 있습니다. Perkeep(위에 링크됨)에는 하나의 큰 바이너리를 연결하는 데 신경 쓰지 않는 증분 개발 속도를 높이는 데 좋은 이러한 모드가 있습니다.

mjibson/esc도 이 작업을 수행하며 웹 앱을 개발할 때 삶의 질을 크게 향상시킵니다. 연결 시간을 절약할 수 있을 뿐만 아니라 웹 애플리케이션 구현에 따라 상당한 시간이 걸리거나 변경 사항을 테스트하기 위해 추가 단계를 반복해야 하는 애플리케이션을 다시 시작하지 않아도 됩니다.

현재 상황의 문제점:

• go:generate 기반 솔루션을 사용하면 각 파일의 두 번째(약간 더 큰) 복사본으로 git 기록이 부풀려집니다.

목표:

• 생성된 파일을 체크인하지 마십시오

음, 이 부분은 생성된 파일을 .gitignore 파일 또는 이에 상응하는 파일에 추가하기만 하면 쉽게 해결할 수 있습니다. 항상 그랬는데...

따라서 Go는 기본적으로 go build 에서 실행되는 자체 "공식" 포함 도구를 갖고 사람들에게 이러한 파일을 규칙으로 무시하도록 요청할 수 있습니다. 그것은 사용 가능한 덜 마법적인 솔루션이 될 것입니다(그리고 기존 Go 버전과 역호환 가능).

나는 단지 브레인스토밍/생각을 크게 하고 있는 중입니다... 하지만 전반적으로 제안된 아이디어가 사실 마음에 듭니다. 🙂

또한, 이후 //go:generate 지시가 자동으로 실행되지 않습니다 go build 의 동작 go build 비트 일치하지 않는 것처럼 보일 수 있습니다 : //go:embed 자동으로 작동하지만 것를위한 //go:generate go generate 수동으로 실행해야 합니다. ( //go:generate 는 빌드에 필요한 .go 파일을 생성하는 경우 이미 go get 흐름을 중단할 수 있습니다.)

//go:generate 는 빌드에 필요한 .go 파일을 생성하는 경우 이미 go get 흐름을 중단할 수 있습니다.

나는 그것에 대한 일반적인 흐름과 내가 일반적으로 사용하는 흐름에 익숙해지는 데 약간의 시간이 걸렸지 go generate 완전히 개발용 도구로 사용하고 파일을 커밋하는 것이라고 생각합니다. 생성합니다.

@bradfitz http.FileSystem 자체를 구현할 필요가 없습니다. 구현에서 http.File 를 구현하는 유형을 제공하는 경우 Open 함수 주위에 래퍼를 제공하여 유형을 http.File 로 변환하는 stdlib http 패키지를 포함하여 누구나 쉽게 사용할 수 있습니다. http.FileSystem

@andreynering //go:generate 와 //go:embed 는 매우 다릅니다. 이 메커니즘은 임의의 코드를 실행하지 않기 때문에 빌드 시 원활하게 발생할 수 있습니다. 나는 그것이 cgo가 go build 일부로 코드를 생성할 수 있는 방법과 유사하다고 믿습니다.

나는 "압축 대 비"노브의 복잡성에 대해 확신하지 못합니다. 그렇게 하면 사람들은 압축, 압축 수준 등을 제어할 수 있는 기능을 추가하기를 원할 것입니다. 추가해야 할 것은 일반 바이트 파일을 포함하는 기능뿐입니다.

나는 단순함을 위한 추진력을 높이 평가하지만 우리는 또한 우리가 사용자의 요구를 충족시키는지 확인해야 합니다.

https://tech.townsourced.com/post/embedding-static-files-in-go/#comparison에 나열된 도구 14개 중 12개는 압축을 지원하며 이는 상당히 일반적인 요구 사항임을 나타냅니다.

이 추론에 동의하는지 잘 모르겠습니다.

다른 라이브러리에 의해 수행되는 압축은 대체가 일반적으로 빌드 시간이 아니라 빌드 전에 생성되기 때문에 후속 빌드에서 성능을 감소시키지 않는다는 점에서 이 제안에 압축을 추가하는 것과 다릅니다.

낮은 빌드 시간은 다른 언어에 비해 Go를 사용하는 분명한 부가가치이며 압축은 스토리지/전송 공간을 줄이기 위해 CPU 시간을 교환합니다. 많은 Go 패키지가 go build 에서 압축을 실행하기 시작하면 빌드 중에 단순히 자산을 복사하여 추가된 시간보다 훨씬 더 많은 빌드 시간이 추가됩니다. 나는 다른 사람들이 하기 때문에 압축을 추가하는 것에 회의적입니다. 초기 설계가 설계상 압축 지원을 추가하는 향후 확장을 방지하지 않는 한, 일부는 불필요한 헤징으로 보일 수 있기 때문에 이를 삽입합니다.

파일 임베딩이 압축 없이는 쓸모가 없는 것과는 다릅니다. 압축은 바이너리 크기를 100MB에서 50MB로 줄이기 위해 꼭 있어야 하는 좋은 기능입니다. 이는 훌륭하지만 내가 생각할 수 있는 대부분의 응용 프로그램에 대한 기능에 대한 명확한 딜브레이커는 아닙니다. . 특히 대부분의 "무거운" 자산이 이미 꽤 잘 압축된 JPEG 또는 PNG와 같은 파일인 경우에는 그렇지 않습니다.

지금은 압축을 유지하고 실제로 많은 사람들이 놓치고 있는 압축을 추가하는 것은 어떻습니까? (그리고 과도한 비용 없이 수행할 수 있음)

위의 @sakjur 의견에 추가하려면 압축이 나에게 직교인 것 같습니다. 일반적으로 자산뿐만 아니라 전체 바이너리 또는 릴리스 아카이브를 압축하고 싶습니다. 특히 Go의 Go 바이너리가 자산 없이 수십 메가바이트에 쉽게 들어갈 수 있는 경우.

@mvdan 내 우려 사항 중 하나는 임베딩이 다른 사전 처리(축소, 타이프스크립트 컴파일, 데이터 압축, 이미지 크런칭, 이미지 크기 조정, 스프라이트 시트)와 함께 수행되는 것을 보았을 때 꽤 자주 있다는 것입니다. html/template 만 사용하는 웹사이트는 예외입니다. 따라서 결국 일종의 "Makefile"을 사용하거나 사전 처리된 콘텐츠를 업로드하게 될 수 있습니다. 그런 의미에서 명령줄 플래그가 주석보다 다른 도구와 더 잘 작동한다고 생각합니다.

내 우려 중 하나는 임베딩이 축소, 타이프스크립트 컴파일, 데이터 압축, 이미지 크런칭, 이미지 크기 조정, 스프라이트 시트와 같은 다른 사전 처리와 함께 수행되는 것을 보았을 때 꽤 자주 있다는 것입니다. html/template만 사용하는 웹사이트는 예외입니다.

감사합니다. 유용한 데이터 포인트입니다. 아마도 압축의 필요성은 보이는 것만큼 일반적이지 않습니다. 그런 경우에는 생략하는 것이 합리적이라는 데 동의합니다.

파일 임베딩이 압축 없이는 쓸모가 없는 것과는 다릅니다. 압축은 바이너리 크기를 100MB에서 50MB로 줄이기 위해 꼭 있어야 하는 좋은 기능입니다. 이는 훌륭하지만 내가 생각할 수 있는 대부분의 응용 프로그램에 대한 기능에 대한 명확한 딜브레이커는 아닙니다. .

바이너리 크기는 많은 go 개발자에게 큰 문제입니다(https://github.com/golang/go/issues/6853). Go는 DWARF 디버그 정보를 압축하여 특히 바이너리 크기를 줄입니다. 비록 이것이 링크 시간에 비용이 발생하더라도 (https://github.com/golang/go/issues/11799, https://github.com/golang/go/) 문제/26074). 바이너리 크기를 반으로 줄이는 쉬운 방법이 있다면 개발자들이 그 기회를 잡을 것이라고 생각합니다.

GOPATH 모드에서는 실제로 도움이 되지 않습니다.

아마도 GOPATH 모드에 있는 경우 Go 팀이 GOPATH에 대한 기능 패리티를 영원히 수행할 계획이 없다고 생각하기 때문에 이 기능은 단순히 적용되지 않습니까? GOPATH에서 지원하지 않는 기능이 이미 있습니다(예: 체크섬 db를 통한 보안, 프록시 서버를 통한 종속성 다운로드, 의미 체계 가져오기 버전 관리).

@bcmills가 언급했듯이 go.mod 파일에 정적 디렉토리 이름을 갖는 것은 이 기능이 <=go1.14 절이 있는 go.mod 파일에서 자동으로 해제될 수 있기 때문에 Go 1.15에서 이 기능을 도입하는 좋은 방법입니다.

즉, 이것은 사용자가 정적 디렉토리 경로를 수동으로 작성해야 함을 의미합니다.

나는 벤더 디렉토리와 _test.go 규약이 어떻게 그들이 Go와 이 두 가지 기능을 훨씬 쉽게 사용할 수 있게 했는지 보여주는 좋은 예라고 생각합니다.

많은 사람들이 공급업체 디렉토리 이름을 사용자 정의하는 옵션을 요청하거나 _test.go 규칙을 다른 것으로 변경할 수 있는 기능을 요청한 기억이 없습니다. 그러나 Go가 _test.go 기능을 도입하지 않는다면 Go에서의 테스트는 오늘날 많이 달라질 것입니다.

따라서 static 보다 덜 일반적인 이름이 충돌을 방지할 가능성이 더 높으므로 기존 디렉토리(vendor 및 _test.go와 유사)를 갖는 것이 마법 같은 주석에 비해 더 나은 사용자 경험이 될 수 있습니다.

잠재적으로 충돌이 적은 이름의 예:

• _embed - _test.go 규칙을 따릅니다.
• go_binary_assets
• .gobin 는 .git 규칙을 따릅니다.
• runtime_files - runtime.Files 구조체와 일치하도록

마지막으로 vendor 디렉토리가 Go 1.5에 추가되었습니다. 이제 새로운 규칙을 추가하는 것도 나쁘지 않을 것 같은데요? 😂

mmap-readonly []byte 노출해야 한다고 생각합니다. 필요에 따라 OS에 의해 페이징된 실행 파일의 페이지에 대한 원시 액세스입니다. bytes.NewReader 만 있으면 다른 모든 것이 그 위에 제공될 수 있습니다.

어떤 이유로든 허용되지 않는 경우 ReaderAt 뿐만 아니라 ReadSeeker . 후자는 전자에서 구성하는 것이 간단하지만 다른 방법은 좋지 않습니다. 단일 오프셋을 보호하고 성능을 망치기 위해 뮤텍스가 필요합니다.

파일 임베딩이 압축 없이는 쓸모가 없는 것과는 다릅니다. 압축은 바이너리 크기를 100MB에서 50MB로 줄이기 위해 꼭 있어야 하는 좋은 기능입니다. 이는 훌륭하지만 내가 생각할 수 있는 대부분의 응용 프로그램에 대한 기능에 대한 명확한 딜브레이커는 아닙니다. .

바이너리 크기는 많은 go 개발자에게 큰 문제입니다(#6853). Go는 이진 크기를 줄이기 위해 DWARF 디버그 정보를 압축합니다. 비록 이것이 링크 시간에 비용이 발생하더라도(#11799, #26074). 바이너리 크기를 반으로 줄이는 쉬운 방법이 있다면 개발자들이 그 기회를 잡을 것이라고 생각합니다.

그것은 확실히 공정한 지적이며 내 주장이 파일 크기와 관련하여 부주의에 찬성하는 주장으로 어떻게 보일 수 있는지 알 수 있습니다. 그것은 내 의도가 아니 었습니다. 내 요점은 여전히 ​​일부 사람들에게 유용할 압축 없이 이 기능을 제공하는 것과 더 일치하며, 장기적으로 적절하게 느껴지는 방식으로 압축을 적절하게 추가하는 방법에 대한 유용한 피드백과 통찰력을 제공할 수 있습니다. 자산은 디버그 정보가 할 수 없는 방식으로 부풀어 오르고 다른 사람이 설치/가져온 패키지 개발자가 구현에서 쉽게 할 수 있는 경우 빌드 성능을 불필요하게 낮추는 것이 더 쉽습니다.

또 다른 옵션은 자산 압축을 빌드 플래그로 만들고 빌드 크기와 시간 간의 타협을 개발자가 아닌 빌더에게 맡기는 것입니다. 그러면 압축이 가치가 있는지 여부를 결정할 수 있는 바이너리의 최종 사용자에게 더 가까운 결정이 내려질 것입니다. Otoh, 이것은 개발과 생산 간의 차이에 대한 증가된 표면적을 생성할 위험이 있으므로 다른 어떤 것보다 명확하고 더 나은 방법이 아니며 옹호하고 싶은 생각이 아닙니다.

현재 자산 임베딩 도구는 -tags dev 빌드할 때 자산 파일에서 콘텐츠를 로드합니다. 이와 같은 일부 규칙은 여기에서도 유용할 것입니다. HTML이나 템플릿을 만지작거릴 때 개발 주기를 상당히 단축시킵니다.

그렇지 않은 경우 호출자는 이 하위 수준 메커니즘을 일부 *_dev.go 및 *_nodev.go 래퍼로 래핑하고 dev 시나리오에 대해 비포함 로딩을 구현해야 합니다. 어렵지는 않지만 그 길은 이 문제에 대한 첫 번째 의견에서 설명한 것과 유사한 도구 폭발로 이어질 것입니다. 이러한 도구는 오늘날보다 더 적은 작업을 수행해야 하지만 여전히 증가할 것입니다.

Go 모듈 외부에서 실행할 때 -tags dev 가 작동하지 않는 것이 합리적이라고 생각합니다(어셋을 로드할 위치를 파악할 수 없음).

입력을 받고 컴퓨터에서 runtime/emved 통해 액세스할 수 있는 내장 파일로 인식되는 특수한 형식의 Go 출력 파일을 생성하는 go tool embed 는 어떻습니까? 그런 다음 간단한 //go:generate gzip -o - static.txt | go tool embed -o static.go 있습니다.

물론 큰 단점은 생성된 파일을 커밋해야 한다는 것입니다.

@DeedleFake 이 문제는 다음으로 시작되었습니다.

go:generate 기반 솔루션을 사용하면 각 파일의 두 번째(약간 더 큰) 복사본으로 git 기록이 부풀려집니다.

이런. 괜찮아요. 죄송합니다.

파일 임베딩이 압축 없이는 쓸모가 없는 것과는 다릅니다. 압축은 바이너리 크기를 100MB에서 50MB로 줄이기 위해 꼭 있어야 하는 좋은 기능입니다. 이는 훌륭하지만 내가 생각할 수 있는 대부분의 응용 프로그램에 대한 기능에 대한 명확한 딜브레이커는 아닙니다. .

바이너리 크기는 많은 go 개발자에게 큰 문제입니다(#6853). Go는 이진 크기를 줄이기 위해 DWARF 디버그 정보를 압축합니다. 비록 이것이 링크 시간에 비용이 발생하더라도(#11799, #26074). 바이너리 크기를 반으로 줄이는 쉬운 방법이 있다면 개발자들이 그 기회를 잡을 것이라고 생각합니다.

필요한 경우 압축 데이터가 커밋되고 포함되며 runtime.Embed 와 압축 해제 인라인을 수행하는 최종 소비자 사이에 계층을 제공하는 패키지가 있습니다.

그리고 1, 2년 후에는 압축 추가에 대한 새로운 문제가 생겨서 정렬될 수 있습니다.

goemb를 작성할 때 15가지 경쟁 표준 중 하나로 이것을 말합니다.

@tv42 는 다음

mmap-readonly []byte 노출해야 한다고 생각합니다. 필요에 따라 OS에 의해 페이징된 실행 파일의 페이지에 대한 원시 액세스입니다.

이 댓글은 놓치기 쉽고 놀라울 정도로 가치가 있습니다.

@tv42 ,

mmap-readonly []byte를 노출해야 한다고 생각합니다. 필요에 따라 OS에 의해 페이징된 실행 파일의 페이지에 대한 원시 액세스입니다. 그 위에 bytes.NewReader만 있으면 다른 모든 것이 제공될 수 있습니다.

이미 읽기 전용인 유형은 string 입니다. 또한 io.ReaderAt 와 달리 크기를 제공하며 표준 라이브러리에 의존하지 않습니다. 그것이 아마도 우리가 폭로하고 싶은 것입니다.

이미 읽기 전용인 유형은 string 입니다.

그러나 전체 생태계 Write 등 작동 []byte . 단순한 실용주의입니다. io.Writer.Write 문서가 말하는 것보다 읽기 전용 속성이 더 이상 문제가 되지 않는 것으로 보입니다.

쓰기는 일시적이라도 슬라이스 데이터를 수정해서는 안 됩니다.

또 다른 잠재적인 단점은 go:generate 있는 디렉토리를 포함할 때 git diff 의 출력을 확인하고 실수로 파일이 있는지 확인할 수 있다는 것입니다. 이 제안으로 - ? 아마도 go 명령이 포함된 파일 목록을 인쇄할까요?

@tv42

그러나 Write 등의 전체 생태계는 []byte에서 작동합니다.

html/template 는 문자열과 함께 작동합니다.

Go에서는 이미 -ldflags -X를 사용하여 일부 문자열(git 버전, 컴파일 시간, 서버, 사용자 등을 설정하는 데 유용)을 설정할 수 있습니다. 이 메커니즘을 확장하여 문자열 대신 io.Readers를 설정할 수 있습니까?

@bradfitz 텍스트가 아닌 데이터에도 여기에 문자열을 사용할 것을 제안합니까? 아이콘 및 작은 이미지 등과 같은 작은 바이너리 파일을 포함하는 것이 일반적입니다.

@tv42 Write 라고 말씀하셨지만 Read 말씀하신 것 같습니다. 당신은 설정할 수 있습니다 string 이에 io.ReaderAt 사용 strings.NewReader , 그래서 문자열을 사용하여이 장벽처럼 보일하지 않습니다.

@andreynering A string 는 모든 바이트 시퀀스를 보유할 수 있습니다.

string 는 모든 바이트 시퀀스를 보유할 수 있습니다.

네, 하지만 주요 의도는 임의의 데이터가 아닌 텍스트를 보유하는 것입니다. 이것은 특히 경험이 부족한 Go 개발자에게 약간의 혼란을 일으킬 수 있다고 생각합니다.

나는 완전히 아이디어를 얻었다. 명확히 해 주셔서 감사합니다.

@ianlancetaylor

Read 는 전달된 슬라이스를 변경 해야 합니다. Write 는 그렇지 않습니다. 따라서 Write 문서에는 이것이 허용되지 않는다고 나와 있습니다. 사용자가 반환된 []byte 쓰지 않아야 한다는 것을 문서화하는 것보다 더 필요한 것은 없습니다.

strings.Reader 가 존재한다고 해서 io.WriteString 가 문자열 작성의 효율적인 구현을 찾을 수 있다는 의미는 아닙니다. 예를 들어 TCPConn 에는 WriteString .

나는 Go에 이와 같은 새로운 기능을 포함하여 소켓에 쓰기 위해 모든 데이터를 강제로 복사하는 것을 싫어합니다.

또한 일반적인 가정은 문자열은 사람이 인쇄할 수 있고 []byte 종종 그렇지 않다는 것입니다. 문자열에 JPEG를 넣으면 터미널이 많이 엉망이 됩니다.

@opennota

그러나 html/template은 문자열과 함께 작동합니다.

예, 이상한 것입니다. 독자가 아닌 경로 이름으로 파일만 사용합니다. 두 가지 응답:

1. 포함된 데이터에 Bytes() []byte 및 String() string 두 가지 방법이 있을 수 없습니다.

2. 모든 단일 요청에 대해 템플릿을 구문 분석하지 않기를 바랍니다. 반면에 JPEG 데이터를 요청하는 모든 요청에 ​​대해 TCP 소켓으로 JPEG 데이터를 보내야 합니다.

@tv42 필요에 따라 WriteString 메소드를 추가할 수 있습니다.

이 기능의 가장 일반적인 용도는 수정되지 않은 데이터를 작성하는 것이 아니므로 이 경우에 최적화해야 한다고 생각하지 않습니다.

이 기능의 가장 일반적인 용도는 수정되지 않은 데이터를 쓰는 것이 아니라

이 기능의 가장 일반적인 용도는 수정되지 않은 이미지/js/css 웹 자산을 제공하는 것입니다.

하지만 내 말을 믿지 말고 Brad's fileembed의 일부 수입업체를 살펴보겠습니다.

#fileembed pattern .+\.(js|css|html|png|svg|js.map)$

#fileembed pattern .*\.png



md5-f8b48fccd03599094034bf2b507e9e67



#fileembed pattern .*\.js$

등등..

일화 데이터의 경우: 이것이 구현된 경우 직장에서 즉시 두 곳에서 사용할 것이며 둘 다 정적 텍스트 파일에 대한 수정되지 않은 액세스를 제공한다는 것을 알고 있습니다. 지금 우리는 //go:generate 단계를 사용하여 파일을 상수(16진수 형식) 문자열로 변환합니다.

나는 지침이 아닌 새 패키지에 투표할 것입니다. 그립을 잡기가 훨씬 쉽고 취급/관리가 더 쉬우며 문서화 및 확장이 훨씬 더 쉽습니다. 예를 들어 "go:generate"와 같은 Go 지시문에 대한 문서를 쉽게 찾을 수 있습니까? "fmt" 패키지에 대한 문서는 어떻습니까? 내가 이걸 가지고 어디로 가는지 보이시죠?

따라서 Go는 기본적으로 go build 에서 실행되는 자체 "공식" 포함 도구를 가질 수 있습니다.

@andreynering 다른 패키지 관리자와 언어 도구가 이를 허용

이 기능에 대해 생각할 때 두 가지 추가 사항이 생각납니다.

• 임베딩 파일은 빌드 캐시와 어떻게 자동으로 작동합니까?
• 재현 가능한 빌드를 방지합니까? 데이터가 어떤 식으로든 변경되면(예: 압축), 재현성을 고려해야 합니다.

첫 번째 주석에 링크된 stuffbin 은 기본적으로 자체 호스팅 웹 애플리케이션이 정적(HTML, JS ...) 자산을 포함할 수 있도록 만들어졌습니다. 이것은 일반적인 사용 사례인 것 같습니다.

컴파일/압축 논의를 제외하고 또 다른 문제점은 다음과 같은 이유로 stdlib에 파일 시스템 추상화가 없다는 것입니다.

• 개발자의 컴퓨터에서 수많은 go run 및 빌드는 자산을 임베딩(선택적으로 압축하는 동안)하는 오버헤드로 인해 부담을 받을 필요가 없습니다. 파일 시스템 추상화를 사용하면 개발 중에 로컬 파일 시스템으로 쉽게 _failover_할 수 있습니다.

• 자산은 예를 들어 웹 애플리케이션의 전체 Javascript 프론트엔드와 같이 개발 중에 능동적으로 변경될 수 있습니다. 임베디드 자산 대신 임베디드와 로컬 파일 시스템 간에 원활하게 전환하는 기능을 사용하면 자산이 변경되었다는 이유로 Go 바이너리의 컴파일 및 재실행을 방지할 수 있습니다.

편집: 결론적으로 내장 패키지가 http.FileSystem보다 나은 파일 시스템과 유사한 인터페이스를 노출할 수 있다면 이러한 문제를 해결할 수 있습니다.

내장 파일 시스템과 로컬 파일 시스템 간에 원활하게 전환하는 기능

확실히 이것은 응용 프로그램 수준에서 구현할 수 있으며 이 제안의 범위를 벗어납니다.

확실히 이것은 응용 프로그램 수준에서 구현할 수 있으며 이 제안의 범위를 벗어납니다.

죄송합니다. 제가 표현한 방식이 모호하다는 것을 방금 깨달았습니다. 나는 임베드 패키지 내부에 파일 시스템 구현을 제안한 것이 아니라 인터페이스, http.FileSystem 보다 나은 것을 제안했습니다. 그러면 애플리케이션이 모든 종류의 추상화를 구현할 수 있습니다.

편집: 오타.

@knadh go run 사용할 때도 작동해야 한다는 데 전적으로 동의합니다. Packr이 이를 처리하는 방식은 정말 좋습니다. 파일이 어디에 있는지 알고 있으며 앱에 포함되지 않은 경우 기본적으로 "개발 모드"가 될 것으로 예상하는 대로 디스크에서 파일을 로드합니다.

Packr의 저자는 또한 Go 모듈에 더 초점을 맞춘 새로운 도구 Pkger를 출시했습니다. 거기에 있는 파일은 모두 Go Module 루트와 관련된 것입니다. 나는 그 아이디어를 정말 좋아하지만 Pkger는 디스크에서 로컬 개발 로딩을 구현하지 않은 것 같습니다. 이 둘의 조합은 놀라운 IMO가 될 것입니다.

이미 실행 중인지는 모르겠지만 "패키지 포함 접근 방식"은 매우 마법적이지만 도구가 호출을 기반으로 파일에 수행할 작업을 추론할 수 있기 때문에 약간의 놀라운 기능도 제공합니다. 예를 들어 API는 다음과 같을 수 있습니다.

package embed
func FileReader(name string) io.Reader {…}
func FileReaderAt(name string) io.ReaderAt {…}
func FileBytes(name string) []byte {…}
func FileString(name string) string {…}

go 도구가 FileReaderAt 대한 호출을 찾으면 데이터가 압축 해제되어야 함을 알고 있습니다. FileReader 호출만 찾으면 압축된 데이터를 저장할 수 있음을 압니다. FileBytes 호출을 찾으면 복사가 필요하다는 것을 알고 FileString 만 찾으면 읽기 전용 메모리에서 제공할 수 있음을 압니다. 등등.

나는 이것이 적절한 go 도구에 대해 이것을 구현하는 합리적인 방법이라고 확신하지 않습니다. 그러나 실제 노브가 없어도 압축 및 제로 카피 임베딩의 이점을 얻을 수 있기 때문에 이것을 언급하고 싶었습니다.

[편집] 또한 물론, 사실 이후에 이러한 추가 맹글링을 추가하고, 먼저 보다 최소한의 기능 세트에 중점을 두도록 하겠습니다. [/편집]

FileReader 호출만 찾으면...

이렇게 하면 리플렉션을 통해 다른 방법을 사용할 수 없습니다.

[편집] 사실 그 의미가 그보다 더 넓은 것 같아요. 사용하면 FileReaderAt 데이터를 압축 해제해야한다는 표시이고, 다음의 사용 FileReaderAt() 임의의 비와 const 입력은 모든 파일을 압축 저장해야한다는 것을 의미한다.

좋은지 나쁜지 모르겠습니다. 매직 휴리스틱은 처음에는 얼굴이 붉어지는 것만큼 유용하지 않을 것이라고 생각합니다.

특수 디렉토리 이름( static/ ) 대신 주석 pragma( //go:embed )를 지지하는 한 가지 인수: 주석을 사용하면 패키지(또는 xtest 아카이브)의 테스트 아카이브에 파일을 포함할 수 있습니다. ) 그러나 테스트 중인 라이브러리는 아닙니다. 주석은 _test.go 파일에 나타나야 합니다.

이것이 모듈의 일반적인 문제를 해결할 것으로 기대합니다. 해당 패키지가 다른 모듈에 있는 경우 다른 패키지의 테스트 데이터에 액세스하기 어렵습니다. 패키지는 _test.go 파일에 //go:embedglob testdata/* 와 같은 주석으로 다른 테스트에 대한 데이터를 제공할 수 있습니다. 패키지는 해당 파일을 가져오지 않고 일반 비테스트 바이너리로 가져올 수 있습니다.

@fd0 ,

임베딩 파일은 빌드 캐시와 어떻게 자동으로 작동합니까?

여전히 작동합니다. 포함된 파일 콘텐츠 해시는 캐시 키에 혼합됩니다.

응용 프로그램 내부에서와 같이 단순히 다음과 같은 경로를 열려고 시도하는 것처럼 실질적으로 투명한 모듈/패키지/메커니즘을 갖는 것이 가능합니까 (또는 좋은 아이디어라도)

internal://static/default.css

파일 함수는 바이너리 내부 또는 대체 위치에서 데이터를 읽습니다.
예: Package.Mount("internal[/<folder>.]", binary_path + "/resources/")

바이너리의 모든 파일과 함께 "internal://"을 생성하려면 실행 경로/자원/개발 모드에 있거나 바이너리에서 파일을 찾을 수 없는 경우(그리고 로깅 목적으로 경고 또는 무언가를 던질 수 있음)

이것은 예를 들어

Package.Mount("internal", binary_path  + "/resources/private/")
Package.Mount("anotherkeyword", binary_path  + "/resources/content/")

아마도 '릴리스' 모드에 있을 때 실행 파일의 경로에 대한 대체 위치를 잠그는 것이 가장 좋지만 개발 모드에서는 이것을 완화합니다(go_path 또는 이와 유사한 폴더의 폴더만 허용).

기본적으로 패키지는 internal:// 또는 다른 키워드를 "마운트"하지만 원하는 경우 사용자가 이름을 바꾸도록 합니다. ex .ReMount("internal","myCustomName") 또는 이와 유사한 것입니다.

또 다른 것은 ... 대체 위치에서 마지막 변경/수정 시간을 확인하고 응용 프로그램 외부에 그러한 파일이 있는 경우 내부 파일을 자동으로 재정의하는 것이 의미가 있습니까(이를 허용하는 플래그가 있을 수 있으며 빌드 전에 프로그래머가 구성할 수 있음)
이것은 새로운 빌드가 만들어 배포될 때까지 기다리고 싶지 않은 초고속 애플리케이션 패치에 필요할 수 있습니다. 폴더를 만들고 거기에 파일을 복사하면 바이너리가 새 빌드로 전환됩니다. 파일.

Windows에서 리소스를 사용하는 것이 가능하거나 의미가 있습니까(리소스의 이진 데이터 blob에서와 같이)
그리고 약간 관련이 없지만 이 패키지는 실행 파일, 매니페스트 데이터 또는 다른 리소스의 번들 아이콘을 처리할 수도 있습니다. 알고보니 윈도우 전용...
빌더가 대체 폴더에 파일의 마지막 수정/변경 날짜를 기록하고 파일이 변경되고 어딘가에 Blob을 캐시하는 경우에만 "데이터 Blob 생성"을 트리거할 수 있다고 상상합니다.
아마도 "캐시" 파일만 생성할 수 있습니다. 사용자가 이러한 번들 파일에서 압축을 활성화하도록 선택하면(결국 압축하기로 결정된 경우) ... 압축이 선택되면 수정된 특정 파일만 빌드 시 다시 압축해야 합니다. , 다른 파일은 캐시에서 바이너리로 복사됩니다.

내가 볼 수있는 한 가지 문제는 패키지가 사용자 정의 이름을 허용하는 경우 "udp, file, ftp, http, https 및 기타 다양한 인기있는 키워드"를 허용하지 않는 것과 같이 일종의 블랙리스트가 필요하다는 것입니다.

바이트 배열/문자열 또는 압축으로 저장하는 경우 ... 어떤 결정을 내리든 나중에 쉽게 업데이트할 수 있는 여지를 남겨 두어야 합니다... 예를 들어 압축 없이 시작할 수 있고 오프셋 및 파일 크기 목록만 있으면 됩니다. 파일 이름을 지정하지만 나중에 압축을 쉽게 추가할 수 있습니다(예: zlib, lzma, 압축 크기, 청크 압축을 풀기에 충분한 메모리를 할당해야 하는 경우 압축되지 않은 크기 등).

실행 파일이 UPX 또는 이에 상응하는 것으로 압축될 수 있다면 개인적으로 기쁠 것입니다. 바이너리가 메모리에서 압축 해제되고 모든 것이 작동할 것이라고 가정합니다.

간접적으로 관련된 몇 가지 생각:

• Go 구문을 사용하는 package embed 접근 방식이 마음에 듭니다.
• 압축 및 기타 조작의 필요성은 이진 크기에 관한 것이 아니라 가장 diff 친화적인 형식의 콘텐츠를 저장소에 저장하려는 것입니다. 누군가가 재생성하는 것을 잊어버리는 "동기화되지 않은" 상태가 없기 때문입니다. "소스"를 변경할 때 압축된 형식을 커밋하고 패키지가 "가져오기 가능" 상태로 유지되도록 합니다. 이러한 점을 다루지 않고 우리는 표준화 문제만 해결하고 있는데, 이는 수용할 수 있지만 이상적이지는 않습니다.
• embed 상호 작용이 선택적으로 "코덱"을 제공할 수 있다면 특정 압축/변환을 ​​적극적으로 지원해야 하는 도구 체인의 필요성을 피할 수 있다고 생각합니다. 코덱을 정확히 정의하는 방법은 통합 구문에 따라 다르지만 다음과 같이 상상합니다.

package embed

type Codec interface {
    // Encode transforms a source representation to an in-binary encoded asset.
    Encode(io.Writer, io.Reader) error

    // Decode transforms an in-binary asset to its active representation that the embedded application wants to use.
    Decode(io.Writer, io.Reader) error
}

이것은 다음과 같이 매우 구체적인 사용 사례를 다룰 수 있습니다.

package main

func NewJSONShrinker() embed.Codec {
   return jsonShrinker{}
}

type jsonShrinker struct{}
func (_ jsonShrinker)  Encode(io.Writer, io.Reader) error {
    // use json.Compact + gzip.Encode...
}
func (_ jsonShrinker)  Decode(io.Writer, io.Reader) error {
    // use gzip.Decode + json.Indent
}

그것을 사용하면 다음과 같이 보일 수 있습니다.

// go:embed file.name NewJSONShrinker

func main() {
    embed.NewFileReader("file.name") // codec is implied by the comment above
}

또는 아마도

func main() {
    f, err := embed.NewFileReaderCodec("file.name", NewJSONShrinker())
    ...
}

두 번째 형식에는 컴파일 타임에 Encode 단계를 수행해야 하기 때문에 툴체인이 사용할 코덱을 정적으로 이해해야 하는 복잡성이 있습니다. 따라서 컴파일 타임에 쉽게 결정할 수 없는 코덱 값은 허용하지 않아야 합니다.

이 두 가지 옵션이 주어지면 매직 코멘트와 코덱을 선택하겠습니다. 그 결과 여기에 명시된 모든 목표를 해결하는 보다 강력한 기능이 제공됩니다. 또한 여기에서 마법의 댓글이 허용되지 않는다고 생각하지 않습니다. 우리는 지금 당장 이 목적을 위해 go:generate 를 통해 이미 허용합니다. 어쨌든 마술 패키지 하나만으로 현재 관용구에서 더 많이 벗어난다고 생각할 수 있습니다. 현재 Go 생태계에는 소스 파일이 툴체인에 추가 소스 파일을 사용하도록 지시하는 기능이 많지 않으며, 현재로서는 마법의 코멘트가 아닌 유일한 것은 import 키워드라고 생각합니다.

압축을 하면 코덱 유형이나 압축 레벨 노브가 전혀 없습니다. 즉, 노브가 전혀 없는 것이 압축을 전혀 지원하지 않는다는 가장 큰 주장입니다.

내가 노출하고 싶은 유일한 선택은 랜덤 액세스 여부입니다. 임의 액세스가 필요하지 않은 경우 도구 및 런타임에서 적절한 압축을 선택하고 사용자에게 노출하지 않을 수 있습니다. 그리고 시간이 지남에 따라 변경/개선될 것입니다.

하지만 @rsc 측에서는 내가 깨달았기 때문에 섰 습니다. 가장 압축할 수 있는 콘텐츠(HTML, JS, CSS 등)는 여전히 임의 액세스를 원하는 콘텐츠입니다. 범위 요청을 지원하는 http.FileServer 를 통해 제공됨)

그리고 우리가 삽입한 Perkeep의 HTML/CSS/JS의 결합된 크기를 보면 압축되지 않은 48KB입니다. Perkeep 서버 바이너리는 49MB입니다. (임베딩된 이미지의 크기는 이미 압축되어 있기 때문에 무시하겠습니다.) 따라서 가치가 없는 것처럼 보이지만 나중에 추가할 수 있습니다.

@rsc와의 토론에서 위의 접근 방식을 혼합하여 수행할 수 있는 것 같습니다.

패키지 런타임에서

package runtime

type Files struct {
     // unexported field(s), at least 1 byte long so Files has a unique address
}

func (f *Files) Open(...) (...) { ...}
func (f *Files) Stat(...) (...) { ...}
func (f *Files) EnumerateSomehow(...) { ...}

그런 다음 코드에서:

package yourcode

//go:embed static/*
//go:embed logo.jpg
var website runtime.Files

func F() {
     ... = website.Open("logo.jpg")
}

그런 다음 cmd/go 도구는 go:embed 주석을 구문 분석하고 해당 패턴을 glob + 해당 파일을 해시하고 &website 사용하여 런타임에 등록합니다.

런타임은 각 파일 주소의 내용과 실행 파일의 위치(또는 ELF/etc 섹션 이름이 무엇인지)에 대한 맵을 효과적으로 가질 것입니다. 그리고 아마도 압축을 하게 되면 랜덤 액세스를 지원하거나 지원하지 않을 수 있습니다.

@gdamore ,

여기에 또 다른 주름이 있습니다. DTrace 소스 코드(임베디드)를 사용하는 다른 프로젝트가 있습니다. 이것은 n과 rn의 차이에 민감합니다.
...
다양한 munging이 트릭을 수행하지 못한다면, 그것은 이 새로운 기능을 사용하는 것에 대한 논쟁입니다.

또한 런타임에 mung하여 go install을 실행하는 Windows 사용자로부터 포함된 캐리지 리턴을 제거할 수 있습니다. 나는 io.Reader 필터를 몇 번 작성했습니다.

하지만 @rsc 의 입장에서는 내가 깨달은 사실 때문에 압축을 하지 않는 편이었습니다. 가장 압축할 수 있는 콘텐츠(HTML, JS, CSS 등)는 여전히 임의 액세스를 원하는 콘텐츠입니다. 범위 요청을 지원하는 http.FileServer를 통해 제공됨)

압축과 랜덤 액세스는 완전히 상호 배타적이지 않습니다. 예를 들어 여기에서 일부 토론을 참조하십시오. https://stackoverflow.com/questions/429987/compression-formats-with-good-support-for-random-access-within-archives

압축과 랜덤 액세스는 완전히 상호 배타적이지 않습니다.

예, 올바른 위치에 도달하기 위해 약간의 오버헤드가 있는 거친 탐색을 원했다면. 이 공간에서 CRFS의 stargz 형식으로 작업을 했습니다 . 하지만 오버헤드가 너무 커서 사람들을 위해 자동으로 그렇게 하고 싶지 않을 것입니다. 나는 당신이 그것을 메모리에 게으르게 부풀릴 수도 있다고 생각하지만 (그리고 sync.Pool과 같은 GC에 그것을 드롭할 수 있다), 그것은 가치가 없어 보인다.

오버 헤드가 너무 커서 사람들을 위해 자동으로 수행하고 싶지 않을 것입니다.

그럴 수 있지. 중요한 질문은 필요가 변경되거나 실험에서 오버헤드가 허용 가능한 것으로 표시되는 경우 나중에 이에 대해 저렴하게 마음을 바꿀 수 있는 API를 선호하는지 여부입니다.

@bradfitz 좋은 지적. 그리고 나는 확실히 할 수 있습니다. FWIW, 내 저장소에서 .d 파일을 볼 때 덜 독성이 있도록 git을 구성했습니다. 여전히 예측 가능하고 git이나 시스템의 변덕에 종속되지 않는다는 점에서 역따옴표가 있는 포함된 문자열의 속성이 유용하다는 것을 알았습니다.

코덱 아이디어에서 얻은 것은 압축이 원하는 유일한 변환이 아니며 사용자가 제공한 코덱 유형을 통해 도구 체인에서 "어떤 코덱"이 아닌 다른 플래그를 무시할 수 있다는 것입니다. 모든 압축 수준 또는 알고리즘, 압축 여부는 사용되는 코덱에 따라 달라야 합니다. 특정 형식과 노브를 제공한다는 의미에서 "압축 지원"을 시도하는 것은 사람들이 요구할 수 있는 모든 변형을 포함하는 거위 추격이 될 것이라는 점에 전적으로 동의합니다. 사실, i18n 데이터를 사전 처리하거나 latlong 에서와 같은 데이터 세트를 처리하는 것과 같은 흔하지 않은 사용에 대해 가장 흥분할 것이므로 여전히 주변 옵션을 고려할 가치가 있다고 생각합니다.

같은 유연성을 제공할 수 있는 다른 방법이 더 좋을 수도 있다고 생각했습니다. // go:embed 지시문은 // go:generate 와 마찬가지로 명령 호출이 될 수 있습니다. 가장 간단한 경우에는 다음과 같습니다.

// go:embed "file.name" go run example.com/embedders/cat file.name

물론 주요 차이점은 명령 호출의 stdout이 제공된 이름 아래에 포함된다는 것입니다. 이 예제는 또한 cat 가 Go가 컴파일되는 모든 곳에서 사용 가능하지 않을 수 있기 때문에 명령 OS를 독립적으로 만드는 방법을 보여주기 위해 go run 가 있는 가장 패키지를 사용합니다.

그것은 변환의 "인코딩" 단계를 처리하며 아마도 "디코드" 단계의 작업은 사용자에게 맡겨질 수 있습니다. runtime/embed 패키지는 인코딩에 관계없이 사용자가 도구 체인에 포함하도록 요청한 바이트를 제공할 수 있습니다. 이것은 사용자가 디코딩 프로세스가 무엇인지 알고 있기 때문에 괜찮습니다.

이것의 한 가지 큰 단점은 포함된 바이트가 zip 또는 기타가 되는 것 외에 여러 파일을 이런 방식으로 포함하는 좋은 방법이 없다는 것입니다. glob은 여전히 ​​zip 명령에 의해 사용될 수 있고 glob에 대해 정말로 관심이 있는 정의 측면에 있기 때문에 실제로 충분할 수 있습니다. 그러나 우리는 이 제안에서 두 가지 기능을 가질 수도 있습니다. 하나는 단순 내장을 수행하고 다른 하나는 생성기 내장을 실행하는 것입니다.

나에게 발생 가능한 한 가지 단점은 가정 퍼가기에 의해 처리되어야, 그것은 빌드에 오픈 종료 단계를 추가하는 것입니다 go build 와 같은 별도의 툴 체인 호출이 필요하지 go generate 수행합니다. 그래도 괜찮다고 생각합니다. 도구는 비용이 많이 드는 작업을 반복하지 않기 위해 자체 캐시를 관리하거나 Go의 캐시를 사용하기 위해 도구 체인과 통신할 수 있습니다. 그것은 해결될 수 있는 문제처럼 들리고 go build 우리를 위해 더 많은 일을 해준다(모듈 가져오기와 같은)의 전반적인 주제에 맞습니다.

이 프로젝트의 목표 중 하나는 Go 빌드에 외부 도구와 go:generate 라인이 필요하지 않도록 하는 것입니까?

그렇지 않은 경우 사용자가 많은 노브로 압축을 원할 경우 make 파일(또는 이와 유사한 것)에서 수행할 수 있고 빌드하기 전에 라인 생성 등을 할 수 있기 때문에 일을 단순하게 유지하고 바이트 슬라이스 또는 문자열만 지원하는 것이 가치가 있는 것 같습니다. 따라서 이 제안의 결과가 무엇이든 간에 그것들을 추가하는 것은 가치가 없어 보입니다.

Make 또는 이와 유사한 것을 요구하지 않는 것이 목표라면 압축을 사용하는 것이 합리적일 수 있다고 생각하지만 개인적으로 저는 바로 Make, go generate 등을 사용하여 압축을 수행한 다음 간단하게 임베드하고 일부 바이트만 임베드할 것입니다. .

@SamWhited ,

이 프로젝트의 목표 중 하나는 Go 빌드에 외부 도구와 go:generate 라인이 필요하지 않도록 하는 것입니까?

예.

사람들이 go:generate, Makefiles 또는 기타 도구를 사용하기를 원하면 오늘날 수십 가지 선택 사항이 있습니다.

우리는 기본적으로 작동하는 이식 가능하고 안전하며 올바른 것을 원합니다. (분명히 말해서, 안전하다는 것은 go:generate가 기본적으로 실행되지 않는 것과 같은 이유로 "go install" 시간에 임의의 코드를 실행할 수 없다는 것을 의미합니다)

@stephens2424

내장 상호 작용이 "코덱"을 선택적으로 제공할 수 있다면 특정 압축/변환을 ​​적극적으로 지원해야 하는 도구 체인의 필요성을 피할 수 있다고 생각합니다.

go build 동안 임의의 코드가 실행되지 않습니다.

go 빌드 중에 임의의 코드가 실행되지 않습니다.

네, 이제 알겠습니다. "소스" 파일만 repo에 커밋하고 "처리된" 파일을 포함하고 패키지를 "가져오기 가능"하게 만들고 go build 간단하고 안전하게 유지하기 위해 조정하는 방법이 없다고 가정합니다. 나는 여전히 여기에서 표준화를 위해 노력하고 있지만, 내 케이크도 먹고 싶기도 하다. 가치가 있습니다! 문제를 잡아주셔서 감사합니다!

@flimzy

이렇게 하면 리플렉션을 통해 다른 방법을 사용할 수 없습니다.

제가 언급한 방법은 없고 기능만 있습니다. 런타임에 검색할 수 없으며 소스에서 이름으로 언급하지 않고 참조할 방법이 없습니다. 그리고 다른 함수에 의해 반환된 인터페이스 값은 동일한 유형일 필요는 없습니다. 실제로 해당 인터페이스를 구현하는 데 필요한 정확히 메서드가 포함된 내보내지 않은 유형이거나 *strings.Reader 의 인스턴스일 것으로 예상합니다

논쟁의 여지는 있지만, 이 아이디어는 임베드 패키지의 내보낸 기능을 값으로 전달하는 데 어려움을 겪습니다. 비록 그것이 문제가 되지는 않겠지만 - 서명에는 내보내지 않은 유형이 포함되어 있으므로(아래 참조) 변수, 인수 또는 해당 유형의 반환을 선언할 수 없습니다. 이론적으로 reflect.ValueOf 자체에 전달할 수 있습니다 . 그것이 실제로 호출할 수 있는지조차 모르겠습니다(내보내지 않은 매개변수 유형의 값을 구성해야 할 것입니다. 반사가 허용한다면 모름).

하지만 그럴 수 있습니다. embed 의 최상위 함수가 값으로 사용되고 모든 포함된 파일에 대해 생성하는 제한을 가정하는 경우에 단순히 비관적일 수 있습니다(가장 간단함). 이는 임베디드 패키지로 극도로 이상하고 쓸모없는 일을 하기로 결정 하면 일부 최적화를 잃게 된다는 것을 의미합니다(어쨌든 약속할 필요는 없음). 공정해 보인다.

사실 그 의미는 그보다 더 광범위하다고 생각합니다. FileReaderAt의 사용이 데이터가 압축 해제되어야 함을 나타내는 경우, 비 const 입력과 함께 FileReaderAt()를 사용하면 모든 파일이 압축되지 않은 상태로 저장되어야 함을 의미합니다.

임베딩을 수행하려면 파일 이름을 정적으로 알아야 하기 때문에 비 const 입력을 허용하는 것은 의미가 없습니다. 하지만 string 를 파일 이름 매개변수의 유형으로 사용하는 것은 정확하지 않았습니다. 이 매개변수는 실제로 내보내지 않은 type filename string 여야 하고 함수 인수 외에는 사용되지 않아야 합니다. 그렇게 하면 형식화되지 않은 문자열 상수가 아닌 것은 전달할 수 없습니다.

@메로비우스

const가 아닌 입력을 허용하는 것은 의미가 없습니다.

나는 우리가 다른 것에 대해 이야기하고 있다고 생각합니다. 접근자 함수에 대한 입력을 의미합니다(예: FileReaderAt() ). const가 아닌 입력이 의미가 있다는 데 동의할 것입니다.

요점은 다음과 같습니다. 100개의 파일을 포함했지만 FileReaderAt(filename) 호출이 있다고 가정합니다. 여기서 filename 는 일정하지 않습니다. 포함된 파일 중 어떤 파일이 이러한 방식으로 액세스되는지 알 수 있는 방법이 없으므로 모두 압축되지 않은 상태로 저장해야 합니다.

@flimzy 우리는 같은 것에 대해 이야기하고 있었는데, const가 아닌 파일 이름이 의미가 있다고 진지하게 생각하지 않았습니다. :) 생각해보면, 그것은 잘못되었고 실수였습니다. 미안합니다. 전체 디렉토리를 glob하거나 포함하고 이를 반복하는 기능은 실제로 매우 중요합니다. 그렇습니다. 아직이 해결 될 수 있다고 생각 - 콜렉션 당 결정을함으로써 예 (DIR / 글로브) 만 상수 이름으로 사람을 선택할 수 -하지만 말했듯이 : 그것은 실제로 API 나 때문에 이동 도구에 대한 슈퍼 적절한을 고려할 것 아니다 얼마나 마법 같은지. 따라서 이와 같은 잡초에 들어가는 것은 아마도 개념에 대해 논의할 가치가 있는 것보다 더 많은 공간을 제공할 것입니다. :)

이전 메시지에서 볼 수 없었고 파일을 Go 바이너리에 포함하는 것을 고려하게 된 또 다른 경우는 일반 go 빌드/설치를 사용하여 C 공유 라이브러리의 래퍼 패키지를 적절하게 배포할 수 없다는 것이었습니다(공유 라이브러리는 출처).

나는 결국 그것을하지 않았지만 확실히이 경우에 대해 다시 생각하게 만들 것입니다. C 라이브러리에는 실제로 공유 라이브러리로 배포하기 쉬운 많은 종속성이 있습니다. 이 공유 라이브러리는 Go 바인딩에 포함될 수 있습니다.

우와!!!

@Julio-Guerra
여전히 디스크에 압축을 풀고 dlopen 및 dlsym을 사용하여 C 함수를 호출해야 한다고 확신합니다.

편집 : 귀하의 게시물을 약간 오해했습니다. 배포용 바이너리 생성에 대해 이야기하고 있다는 것을 깨달았습니다.

http 정적 자산 외부에서 메모리에 대한 포인터에 필요한 임베디드 blob의 경우 이미 처리 중인 임베디드 메모리에 대한 포인터를 반환하는 함수가 있으면 좋을 것입니다. 그렇지 않으면 새 메모리를 할당하고 io.Reader에서 복사본을 만들어야 합니다. 그것은 두 배의 메모리를 소모합니다.

@glycerine , 역시 string 입니다. string 는 포인터와 길이입니다.

컴파일 시간에 실행할 코드를 표시하고 런타임에 결과를 제공하는 방법이 있으면 좋지 않을까요? 그런 식으로 모든 파일을 읽고 컴파일 타임에 원하는 경우 압축하고 런타임에 액세스할 수 있습니다. 파일 내용을 미리 로드할 때 작동하므로 일부 계산에서는 작동합니다.

@burka 스레드에서 이전에 말했듯이 go build 는 임의의 코드를 실행하지 않습니다.

@burka , 명시적으로 범위를 벗어났습니다. 그 결정(컴파일 시 코드 실행 없음)은 오래전에 내려진 것이며 이는 해당 정책을 변경하는 버그가 아닙니다.

이 제안의 부작용은 이동 프록시가 저장 파일을 이동 파일로만 최적화할 수 없다는 것입니다. 프록시는 Go 코드에 Go가 아닌 파일이 포함되어 있는지 알 수 없기 때문에 전체 저장소를 저장해야 합니다.

프록시가 이미 이를 위해 최적화되어 있는지는 모르겠지만 언젠가는 그들이 원할 수도 있습니다.

@leighmcculloch 그래도 요즘은 그렇지 않은 것 같아요. Go 패키지의 모든 비 Go 파일은 go test 필요할 수 있으므로 모듈 아카이브에 포함되어야 합니다. 또 다른 예로 cgo용 C 파일이 있을 수도 있습니다.

이것은 흥미로운 방향이며 우리의 사용 사례에 꼭 필요합니다.

즉, 요구 사항이 다른 다양한 사용 사례가 있다고 생각하지만 _how_에 대해 언급하는 대부분의 사람들은 자신의 사용 사례를 암묵적으로 구상하고 있지만 명시적으로 정의하지는 않습니다.

파일 임베딩 솔루션에 대한 다양한 사용 사례 와 각 사용 사례가 제시 하는 과제 를 설명 할 수 있다면 도움이 될 수 있습니다. 최소한 저에게는 정말 도움이 됩니다.

예를 들어, 우리의 주요 사용 사례는 HTML+CSS+JS+JPG+etc를 포함하여 go 앱이 실행될 때 http.FileServer 제공할 수 있도록 해당 파일을 디렉토리에 쓸 수 있도록 하는 것입니다. . 사용 사례가 나는 독자를 논의 읽고 우리가 접근로 이동에서 파일을 필요로하지 않기 때문에 작가가 나에게 외국이었다 의견의 대부분은, 우리가 할 점을 감안 go-bindata (이기는하지만 _ 디스크에 복사 아마도 우리가 아직 고려하지 못한 더 나은 기술을 활용할 수 있는 방법이 있을 것입니다.)_

그러나 우리의 과제는 다음과 같습니다. 우리는 일반적으로 디버거와 함께 GoLand를 사용하며 웹 앱에서 지속적으로 변경 작업을 수행할 것입니다. 따라서 개발 중에 소스 디렉토리에서 직접 파일을 로드하려면 http.FileServer 가 필요합니다. 그러나 앱이 실행될 때 http.FileServer 는 임베딩 솔루션이 파일을 작성한 디렉토리에서 해당 파일을 읽어야 합니다. 즉, 컴파일할 때 go-bindata를 실행하여 파일을 업데이트한 다음 Git에 체크인해야 합니다. 그리고 그것은 모두 일반적으로 go-bindata 로 작동 가능하지만 확실히 아이디어는 아닙니다.

그러나 다른 경우에는 실제로 컴파일된 실행 파일을 실행해야 하므로 실행 중인 프로그램에 디버거를 연결할 수 있지만 여전히 해당 프로그램이 go-bindata 로 작성된 임베디드 파일이 있는 디렉토리가 아닌 소스 디렉토리에서 파일을 로드하도록 할 수 있습니다.

이것이 우리의 사용 사례이자 과제입니다. 다른 사람들은 다른 사용 사례 및 관련 문제 세트를 명시적으로 정의할 수 있으므로 이러한 토론은 다양한 문제 공간을 명시적으로 다룰 수 있고/또는 이러한 노력이 주어진 문제 공간의 특정 요구를 해결하지 못할 것임을 명시적으로 나타낼 수 있습니까?

고려해주셔서 미리 감사드립니다.

사용 사례로 언급되지 않았기 때문에 우리는 template.ParseFiles를 통해 액세스하는 템플릿 디렉토리에 대해서도 이점을 얻을 수 있습니다.

go.mod 를 통해 선택하는 방법에 대한 가장 깨끗한 접근 방식을 찾을 수 있습니다. 이것은 (기존 프로젝트가 그것을 사용하기 위해 옵트인해야 하기 때문에) 역호환성을 보장하고 어떤 파일이 필요한지 결정하기 위한 도구(예: go proxies)를 허용합니다. go mod init 명령은 새 프로젝트의 기본 버전을 포함하도록 업데이트되어 향후 더 쉽게 사용할 수 있습니다.

디렉토리를 표준 이름으로 설정하거나(선택이 필요한 경우 더 깨끗하고/간단한 이름이 될 수 있음) 디렉토리 이름을 go.mod 자체에 정의하고 사용자가 이름을 선택하십시오(그러나 go mod init 제공하는 기본값이 있습니다.

내 생각에 이와 같은 솔루션은 사용 편의성과 "마법"이 적은 균형을 달성합니다.

@jayconrod 는 다음

특수 디렉토리 이름(static/) 대신 주석 pragma(//go:embed)를 지지하는 한 가지 인수: 주석을 사용하면 라이브러리가 아닌 패키지(또는 xtest 아카이브)에 대한 테스트 아카이브에 파일을 포함할 수 있습니다. 테스트 중.

이것은 정말 좋은 관찰입니다. 특별한 디렉토리 이름을 사용하려는 경우 친숙한 메커니즘을 사용할 수 있습니다. 모든 빌드의 경우 static_test static , 테스트 빌드의 경우 static_amd64 , amd64 빌드의 경우

정적 디렉터리에 매니페스트 파일이 있을 수 있습니다(빈 매니페스트가 주어지면 기본값은 매니페스트를 제외한 모든 것을 포함함). 여기에는 glob이 포함되고 빌드 태그 및 나중에 압축 등을 지정할 수 있습니다.

한 가지 장점은 go list가 매니페스트가 포함된 디렉토리에 도달하면 해당 트리를 건너뛸 수 있다는 것입니다.

한 가지 단점은 매우 haccess를 얻을 수 있고 감사하지 않을 수 있다는 것입니다.

파일을 패키지로 묶기 위한 간단한 제로 노브 메커니즘은 패키지 디렉토리의 특수 디렉토리 go.files 수 있습니다(모듈의 go.mod 와 유사). 심볼을 내보내도록 선택하지 않는 한 액세스는 해당 패키지로 제한됩니다.

편집: 단일 기능 runtime/files 제안:

package files

func Open(name string) (io.ReadCloser, error) {
    // runtime opens embedded file based on caller package
    return rc, nil
}

package foo

import "runtime/files"

func ReadPackageFile(name string) ([]byte, error) {
    rc, err := files.Open(name)
    if err != nil {
        return nil, err
    }
    defer rc.Close()
    return ioutil.ReadAll(rc)
}

import "C" 접근 방식은 이미 "마법" 가져오기 경로에 대한 선례를 설정했습니다. IMO 그것은 꽤 잘 작동했습니다.

사용 사례로 언급되지 않았기 때문에 우리는 template.ParseFiles를 통해 액세스하는 템플릿 디렉토리에 대해서도 이점을 얻을 수 있습니다.

또 다른 문제가 있습니다. 바이너리에 필요한 모든 파일이 포함될 수 있지만 바로 그 파일이 개발자가 제공하는 기본값이 됩니다. 그러나 임프린트 또는 개인 정보 보호 정책과 같은 템플릿은 최종 사용자가 사용자 지정할 수 있어야 합니다. 내가 아는 한 그것은 기본 파일을 내보내고 런타임에 바이너리가 사용자 정의 파일을 사용하도록 하거나 임베디드 버전을 사용자 정의 파일로 대체하는 어떤 방법이 있어야 함을 의미합니다.

내장된 리소스를 '내보내기' 및 '바꾸기'하는 기능이 있는 API를 제공하면 가능하다고 생각합니다. 그런 다음 개발자는 최종 사용자에게 몇 가지 명령줄 옵션을 제공할 수 있습니다(내부적으로 언급된 API 호출 사용).

물론 이 모든 것은 배포를 확실히 용이하게 하는 일종의 임베딩이 실제로 있을 것이라는 가정을 기반으로 합니다.

문제를 열어주셔서 감사합니다. 직장에서 우리는 거의 모든 Golang 프로젝트에 파일을 임베딩해야 하므로 동일한 기능 아이디어에 대해 생각했습니다. 기존 라이브러리는 잘 작동하지만 이것이 Golang이 비명을 지르는 기능이라고 생각합니다. 단일 정적 바이너리로 변환하도록 만들어진 언어입니다. 개발자 친화적이고 보편적인 API를 사용하여 필수 자산 파일을 바이너리에 로드할 수 있도록 함으로써 이를 수용해야 합니다.

선호하는 구현 세부 정보를 빠르게 제공하고 싶습니다. 여러 사람들이 마법의 주석과 같은 또 다른 신호가 필요하지 않고 내장된 파일을 읽을 수 있는 API를 자동으로 제공하는 것에 대해 이야기했습니다. 접근 방식에 친숙하고 프로그래밍 방식의 구문을 제공하기 때문에 그렇게 해야 한다고 생각합니다. 이전에 언급한 것처럼 runtime/embed 특수 패키지를 선택하면 이를 만족시킬 수 있으며 향후 쉽게 확장할 수 있습니다. 다음과 같은 구현이 나에게 가장 의미가 있습니다.

type EmbedPackage interface {
    Bytes(filename string) []bytes
    BytesCompressed(filename string, config interface{}) []bytes // compressed in-binary as configured by some kind of config struct, memoizes decompression during runtime on first access
    Reader(filename string) io.Reader
    File(filename string) os.File // readonly and contains all metadata
    Dir(filepath string) []os.File 
    Glob(pattern string) []os.File // like filepath.Glob()

    // maybe? this could allow to load JSON, YAML, INI, TOML, etc files more easily
    // but would probably be too much for the std lib implementation
    Unmarshal(filename string, config interface{}, ptr interface{}) 
}

코드의 어딘가에서 해당 패키지를 사용하면 컴파일러가 자동으로 포함하여 해당 파일을 런타임에 제공하도록 트리거해야 합니다.

// embed a file that is compressed in-binary and automatically decompressed on first access
var LongText = embed.BytesCompressed("legal.html", embed.Config{ Compression: "gzip", CompressionLevel: "9" })

// loads a single file as reader for easy access
var FewLinesOfText = bufio.NewReader(embed.Reader("lines.txt"))
for _, line := range FewLinesOfText.ReadLines() { ... }

// embeds all files in the directory
var PdfFontFiles = embed.Dir("/fonts")

// unmarshals file into custom config
var PdfProcessingConfig MyPdfProcessingConfig
embed.Unmarshal("/pdf_conversion.json", embed.Config{ Encoding: "text/json" }, &PdfProcessingConfig)

또한 이미 스레드에서 이미 언급한 go.mod 디렉토리 또는 그 아래 1 디렉토리 레벨에 있는 파일로 가져오기를 제한한다면 보안 문제와 재현성은 문제가 되지 않을 것이라고 생각합니다. 절대 임베드 경로는 해당 디렉토리 수준을 기준으로 확인됩니다.

컴파일 프로세스 중에 파일에 액세스하지 못하면 컴파일러 오류가 생성됩니다.

바이너리 뒤에 zip 아카이브를 만들어 효과적으로 자동 압축 풀림 바이너리가 될 수도 있습니다. 일부 사용 사례에서 이것이 유용할까요? 여기에서 실험으로 수행했습니다: https://github.com/sanderhahn/gozip

Go에는 이미 "testdata"가 있습니다. 단위 테스트는 일반 IO를 사용하여 원하는 작업을 수행합니다. 테스트 범위는 콘텐츠가 배송되지 않음을 의미합니다. 프릴, 마술, 압축된 컨테이너 논리, 구성 가능한 간접 참조, META-INF가 없다는 것만으로 알 수 있습니다. 아름답고 단순하며 우아합니다. 번들 런타임 범위 종속성을 위한 "data" 폴더가 없는 이유는 무엇입니까?

Github ea에서 기존 Go 프로젝트를 쉽게 스캔하고 이미 "data" 폴더를 사용하고 있으므로 조정이 필요한 여러 프로젝트를 만들 수 있습니다.

나에게 명확하지 않은 또 다른 것. a의 설명은 static 디렉토리 우리가 토론하면 100 % 나에게 분명하다 static _source_ 디렉터리 또는 static 파일을 사용할 수 _at 될 것이다 디렉토리

그리고 이 구분은 개발 프로세스 및 개발 중인 디버깅 코드와 관련이 있기 때문에 특히 중요합니다.

@mikeschinkel 빌드 시 임베딩이 발생한다는 것은 원래 게시물에서 매우 분명합니다.

go install / go build 자동으로 임베딩 수행

원본 게시물과 위의 일부 댓글에서도 런타임에 파일을 로드하는 "dev" 모드에 대해 설명합니다.

@mvdan 답변 감사합니다. 따라서 제안된 /static/ 디렉토리가 앱 저장소, 패키지 저장소 및/또는 둘 다의 루트에 상대적이라는 것을 의미한다고 생각하십니까?

그리고 런타임 파일의 위치는 개발자가 파일을 배치하려는 위치에 전적으로 의존합니까?

그것이 모두 사실이고 논리적으로 보인다면 디버깅 정보로 컴파일된 프로그램이 선택적으로 소스 위치에서 파일을 로드하여 많은 추가 및 비표준화된 로직 및 코드 없이 디버깅을 용이하게 할 수 있다는 것이 도움이 될 것입니다.

위에서 언급한 모듈 프록시 몇 사람. 이 기능의 좋은 디자인에 대한 훌륭한 리트머스 테스트라고 생각합니다.

오늘날에는 사용자 코드를 실행하지 않고 빌드에 사용되지 않는 파일을 제거하는 실행 가능한 모듈 프록시를 구현하는 것이 가능할 것 같습니다. 위의 디자인 중 일부는 모듈 프록시가 포함되어야 하는 정적 파일을 파악하기 위해 사용자 코드를 실행해야 함을 의미합니다.

사람들은 또한 go.mod를 옵트인으로 언급했습니다.

아이디어: go.mod 파일의 사양? 다른 도구가 구문 분석하기 쉽게 만듭니다.

module github.com/foo/bar

data internal/static ./static/*.tmpl.html

이것은 컴파일 타임에 파일 데이터로 패키지를 생성합니다. 여기에서는 Glob 구문이 좋을 수 있지만 단순화하고 디렉토리를 포함하는 것만으로 충분할 수 있습니다. (제외: ** glob 구문의 경우 +1입니다.)

import "github.com/foo/bar/internal/static"

f, err := static.Open("static/templates/foo.tmpl")

StripPrefix와 같은 것이 여기에는 좋을 수 있지만 필수는 아닙니다. 원하는 파일 경로를 사용하는 래퍼 패키지를 쉽게 만들 수 있습니다.

다음과 같이 더 단순화할 수 있습니다.

module github.com/foo/bar

data ./static/*.tmpl.html

import "runtime/moddata"

moddata.Open("static/foo.tmpl")

그러나 moddata가 호출하는 패키지/모듈에 따라 다른 동작을 갖는다는 것은 다소 직관적이지 않습니다. 헬퍼(예: http.Filesystem 변환기)를 작성하기가 더 어려워집니다.

오늘날에는 사용자 코드를 실행하지 않고 빌드에 사용되지 않는 파일을 제거하는 실행 가능한 모듈 프록시를 구현하는 것이 가능할 것 같습니다. 위의 디자인 중 일부는 모듈 프록시가 포함되어야 하는 정적 파일을 파악하기 위해 사용자 코드를 실행해야 함을 의미합니다.

여기에 큰 변화가 없을 것이라고 생각합니다. 특히, C 코드는 이미 트리에 모든 파일을 포함할 수 있으므로 이를 수행하려는 모듈 프록시는 C를 구문 분석해야 합니다. 그 시점에서 우리가 도입하는 마법의 주석이나 API가 무엇이든 작은 단계가 될 것 같습니다.

위의 디자인 중 일부는 모듈 프록시가 포함되어야 하는 정적 파일을 파악하기 위해 사용자 코드를 실행해야 함을 의미합니다.

"go 도구는 빌드하는 동안 사용자 코드를 실행해서는 안 된다"는 것이 여기에서 넘지 않을 모래에 그려진 선이라는 것이 꽤 분명하다고 생각합니다. 그리고 go 도구가 사용자 코드를 실행할 수 없다면 코드 없이 포함할 파일을 말할 수 있어야 합니다.

나는 이 사용 사례에 대한 다양한 생각을 설득력 있는 것으로 압축하려고 노력해 왔으며, 따라서 @broady가 제안한 것에 큰 +1이 되었습니다. 제가 생각한 내용이 대부분 반영된 것 같아요. 그러나 키워드는 명사 data 대신 embed 동사여야 한다고 생각합니다.

1. 포함된 파일은 특별한 주석이나 매직 패키지가 있는 것이 아니라 가져와야 하는 것처럼 느껴집니다. 그리고 Go 프로젝트에서 go.mod 파일은 개발자가 필요한 모듈/파일을 지정할 수 있는 곳이므로 포함을 지원하도록 확장하는 것이 좋습니다.

2. 게다가, 임베디드 파일 모음은 일회성 구문을 사용하여 Go 프로젝트에 임시로 추가되는 것보다 패키지가 포함될 수 있다면 더 가치 있고 재사용할 수 있을 것 같습니다. 여기서 아이디어는 임베디드가 패키지로 구현되면 사람들이 Github을 통해 개발하고 공유할 수 있고 다른 사람들이 프로젝트에서 사용할 수 있다는 것입니다. 다음을 포함하는 GitHub의 커뮤니티 유지 및 무료 사용 패키지를 상상해 보십시오.

   NS. 각 파일에 해당 국가의 모든 우편 번호가 포함된 국가의 파일,
   NS. 브라우저 식별을 위해 알려진 모든 사용자 에이전트 문자열이 포함된 파일,
   씨. 세계 각국의 국기 이미지,
   NS. Go 프로그램에서 일반적으로 발생하는 오류를 설명하는 심층 도움말 정보,
   이자형. 등등...

3. 패키지에서 파일을 열고 읽는 데 사용할 수 있는 goembed:// 와 같은 새로운 URL 구성표(또는 기존 구성표

   data, err := ioutil.ReadFile("goembed://postal-codes.txt")    
   if (err != nil) {
     fmt.Println(err)
   }
   

위의 개념을 사용하면 _"마법"_처럼 느껴지지 않습니다. 모든 것이 의도된 것처럼 느껴지는 메커니즘에 의해 우아하게 처리될 것입니다. 필요한 확장은 거의 없습니다. go.mod 새 동사 하나와 Go에서 내부적으로 인식할 새 URL 체계 하나. 다른 모든 것은 Go에서 있는 그대로 제공됩니다.

내가 지금 하는 일

나는 지금 이것을 위해 code.soquee.net/pkgzip 를 사용합니다(전역 상태 및 가져오기 부작용을 피하기 위해 API를 변경하는 statik 의 포크입니다). 내 일반적인 워크플로(적어도 웹 앱에서)는 ZIP 파일에 번들된 자산을 포함하고 golang.org/x/tools/godoc/vfs/zipfs 및 golang.org/x/tools/godoc/vfs/httpfs 사용하여 제공하는 것입니다.

go:embed 접근 방식

go:embed 접근 방식을 채택하는 것을 방해하는 두 가지가 있습니다.

1. 생성된 코드는 문서에 표시되지 않습니다.
2. 자산이 코드 기반 전체에 흩어져 있을 수 있습니다(이는 외부 도구와 go:generate 를 사용하는 경우에도 마찬가지입니다. 이것이 내가 일반적으로 빌드하기 전에 다양한 자산 세트를 생성하기 위해 makefile을 사용하는 것을 선호하는 이유입니다). makefile에서 모두 볼 수 있음)

또한 위에 포함하지 않은 문제가 있습니다. 자산이 패키지의 일부가 되는 기능일 수 있기 때문입니다(전체 모듈과 반대)는 빌드 태그, 테스트 패키지 등의 모든 복잡성을 의미합니다. . 적용하려면 해당 패키지에 대해 공개인지 비공개인지 지정하는 방법이 필요합니다. 이것은 추가 빌드 복잡성처럼 보입니다.

내가 좋아하는 점은 자산을 더 쉽게 가져올 수 있는 라이브러리를 작성할 수 있다는 것입니다. 예. 글꼴을 포함하는 단일 Go 파일이 있는 라이브러리 또는 일부 아이콘을 게시할 수 있고 다른 go 패키지처럼 가져올 수 있습니다. 앞으로는 단순히 가져오기만 하면 아이콘 글꼴을 얻을 수 있습니다.

import "forkaweso.me/forkawesome/v2"

임베디드 패키지 접근 방식

이 모든 것이 명시적이고 정상적인 Go 코드라는 아이디어는 좋지만 이것이 표준 라이브러리 외부에서 구현할 수 없는 또 다른 마법 패키지라는 생각은 싫습니다 .

그러한 패키지가 언어 사양의 일부로 정의됩니까? 그렇지 않은 경우 Go 코드가 다른 구현 사이에서 중단되는 또 다른 장소가 되며, 이것도 좋지 않습니다. 이 파손을 방지하기 위해 외부 도구를 계속 사용할 것입니다.

또한 다른 사람들이 언급했듯이 이것이 빌드 시 수행된다는 사실은 이 패키지가 문자열 리터럴 또는 상수만 인수로 사용할 수 있음을 의미합니다. 현재로서는 이것을 타입 시스템에 표현할 방법이 없고, 혼동의 여지가 있을 것으로 생각됩니다. 이것은 상수 함수와 같은 것을 도입하여 해결할 수 있지만, 지금 우리는 주요 언어 변경을 이야기하여 시작하지 못하게 만듭니다. 다른 방법으로는 이 문제를 해결할 수 있는 좋은 방법이 없습니다.

잡종

나는 하이브리드 접근 방식의 아이디어를 좋아합니다. 댓글을 재사용하는 대신(사방에 흩어져 있고 개인적인 메모로 기분이 좋지 않음) 모든 자산을 한 곳에 모아보고 싶습니다. go.mod 파일이 다른 것과 마찬가지일 것입니다. 말했다 :

module forkaweso.me/forkawesome/v2

go 1.15

embed (
    fonts/forkawesome-webfont.ttf
    fonts/forkawesome-webfont.woff2
)

이는 자산이 별도의 모듈을 생성하지 않고 임의의 빌드 태그에 의해 또는 임의의 패키지(예: _testing 패키지)에 포함되거나 제외될 수 없음을 의미합니다. 이러한 복잡성 감소가 바람직할 수 있다고 생각합니다(가져오려는 라이브러리에는 빌드 태그가 숨겨져 있지 않으며 라이브러리를 가져오면 포함해야 하기 때문에 올바른 자산이 없는 이유를 알 수 없습니다) 하지만 YMMV. 이것이 바람직하다면 주석과 같은 pragma는 코드를 생성하지 않고 대신 내가 go.mod 버전에 대해 설명하는 것과 동일한 접근 방식을 사용한다는 점을 제외하고 계속 사용할 수 있습니다.

원래 제안과 달리 이것은 코드를 생성하지 않습니다 . 대신, 예를 들어 기능. ELF 파일의 데이터 섹션 읽기(또는 사용 중인 OS에 상관없이 저장됨)는 적절한 위치에 추가됩니다(예: os 또는 debug/elf 등). 그런 다음 선택적으로 OP에 설명된 패키지와 똑같이 작동하는 새 패키지가 생성될 것입니다. 단, 마법처럼 내장된 자체를 수행하는 대신 내장된 파일을 읽는 것뿐입니다(즉, 표준 라이브러리 외부에서 구현할 수 있음을 의미합니다. 원한다면).

이것은 문자열 리터럴만 인수로 허용하도록 매직 패키지를 제한해야 하는 것과 같은 문제를 해결하지만 포함된 자산이 실제로 어디에서나 사용되는지 확인하기가 더 어렵다는 것을 의미합니다. 또한 추가 항목을 가져와야 하는 유일한 패키지는 새 패키지 자체이기 때문에 표준 라이브러리 패키지 간의 새로운 종속성을 방지합니다.

var IconFont = embed.Dir("forkaweso.me/forkawesome/v2/fonts/")
var Logo = embed.File("images/logo.jpg")

위에서 볼 수 있듯이 모듈에 리소스를 배치하면 원하는 경우 여전히 해당 특정 모듈로 범위를 지정할 수 있습니다. 실제 API와 자산을 선택하는 방법에 약간의 작업이 필요할 수 있습니다.

또 다른 아이디어 대신 동사의 새로운 종류를 추가 embed 에서 go.mod , 우리는 패키지의 새로운 종류를 소개 할 수는에 go.mod 수입 및 사용됩니다 데이터 패키지, 일반적인 방법. 다음은 밀짚맨 스케치입니다.

패키지에 정확히 하나의 .go 파일 static.go 포함되어 있고 해당 파일에 주석과 패키지 절만 포함되어 있으면 패키지는 데이터 패키지입니다. 가져올 때 cmd/go는 결과 바이너리에 포함된 파일에 대한 액세스를 제공하는 내보낸 기능으로 패키지를 채웁니다.

실제 패키지라면 internal 규칙이 적용되고 API에 추가하지 않고도 액세스 제어가 가능하다는 의미입니다.

그러면 디렉터리에 .go 아닌 모든 파일과 하위 폴더(실제 코드 규칙 없음)를 자동으로 포함하는 것은 어떻습니까?

패키지에 정확히 하나의 .go 파일 static.go 가 포함되어 있고 해당 파일에 주석과 패키지 절만 포함되어 있으면 패키지는 데이터 패키지입니다.

빌드 태그를 적용하기 전에 이 검사를 수행합니까? 그렇다면 피해야 할 또 다른 특별한 경우처럼 보입니다. 그렇지 않은 경우 패키지가 일부 빌드 태그의 경우 표준 Go 패키지로 표시되고 다른 태그의 경우 데이터 패키지로 표시될 수 있습니다. 이상해 보이지만 어쩌면 바람직한 일일까요?

@flimzy
그렇게 하면 하나의 태그로 포함된 파일을 사용하고 생성된 패키지와 동일한 fns/vars를 정의하고 다른 태그를 사용하여 다른 방식(원격일 수 있음)으로 파일을 제공할 수 있습니다.

래퍼 함수를 ​​생성하는 빌드 플래그가 있으면 공백을 채우면 됩니다.

@josharian

패키지에 정확히 하나의 .go 파일 static.go 가 포함되어 있고 해당 파일에 주석과 패키지 절만 포함되어 있으면 패키지는 데이터 패키지입니다.

우편 번호 조회와 같은 고유한 도메인별 기능이 있는 "데이터" 패키지를 상상할 수 있습니다. 방금 제안한 접근 방식은 원시 데이터 이외의 다른 것을 허용하지 않으므로 데이터와 함께 논리를 패키징할 수 있는 이점이 무효화됩니다.

우편 번호 조회와 같은 고유한 도메인별 기능이 있는 "데이터" 패키지를 상상할 수 있습니다.

my.pkg/postalcode의 기능을 노출하고 my.pkg/postalcode/data(또는 my.pkg/postalcode/internal/data)에 데이터를 넣을 수 있습니다.

나는 당신이 제안한 방식으로 그것을 하는 것이 매력적이라고 ​​생각하지만 그것은 많은 질문을 제기합니다. 이전 버전과의 호환성은 어떻게 작동합니까? 데이터 패키지를 어떻게 표시합니까? 패키지에 cmd/go가 추가할 기능과 충돌하는 기능이 있으면 어떻게 합니까? (나는 이것들에 답이 없다고 말하는 것이 아니라, 대답하지 않아도 되는 것이 더 간단하다는 것입니다.)

@josharian , 위의 유형 확인 주석을 고려하십시오(https://github.com/golang/go/issues/35950#issuecomment-561443566).

@bradfitz 예, 이것은 언어 변경이며 go/types 지원이 필요합니다.

실제로 언어 변경 없이 이를 수행할 수 있는 방법이 있습니다. cmd/go가 채우는 내용과 정확히 일치하는 본문 없는 함수를 포함하려면 static.go가 필요합니다.

cmd/go가 채울 내용과 정확히 일치하는 본문 없는 기능을 포함하려면 static.go가 필요합니다.

catch all embed.File() 대신 파일별 함수를 생성하면 자산별 내보내기 제어가 쉬워집니다.

따라서 생성된 항목은 다음과 같습니다.

EmbededFoo() embed.Asset {...}
embededBar() embed.Asset {...}

4개월 전에 정적 파일에 대해 작성한 블로그 게시물 입니다. 결론의 마지막 문장을 참고하세요 :-)

@josharian

my.pkg/postalcode의 기능을 노출하고 my.pkg/postalcode/data(또는 my.pkg/postalcode/internal/data)에 데이터를 넣을 수 있습니다.

그것은 - 우아하지만 - 내 우려를 해결할 수 있습니다.

이전 버전과의 호환성은 어떻게 작동합니까?

BC 우려가 여기에 어떻게 적용되는지 모르겠습니다. 자세히 설명해 주시겠습니까?

데이터 패키지를 어떻게 표시합니까?

으로 embed 에 문 go.mod ?

아마도 나는 당신이 묻는 것을 따르지 않을 것입니다.

그러나 나는 그것을 뒤집을 것입니다. 데이터만 있는 패키지를 어떻게 표시합니까?

패키지에 cmd/go가 추가할 기능과 충돌하는 기능이 있으면 어떻게 합니까?

1. 제안된 접근 방식을 사용하면 cmd/go가 기능을 추가할 필요가 없다고 생각합니다.

2. cmd/go가 기능을 추가해야 하는 경우에도 _existing_ 패키지의 충돌 동작은 _undefined_가 될 것이라고 생각합니다.

   제안서는 개발자가 단일 책임 원칙을 따른다고 가정하므로 데이터가 있는 패키지만 데이터 중심 패키지로 빌드해야 하며 기존 논리 중심 패키지에 데이터를 추가하지 않아야 합니다.

   물론 개발자는 기존 패키지에 추가 _할 수_ 있으며 이 경우 동작이 정의되지 않습니다. IOW, 개발자가 관용구를 무시하면 미지의 영역에 있게 됩니다.

나는 이것들에 답이 없다고 말하는 것이 아니라 답을 하지 않아도 되는 것이 더 간단하다는 것입니다.

대답이 간단하다고 생각하는 것 외에는. 적어도 지금까지 포즈를 취한 사람들에게는.

기호 또는 기호에 대한 값을 추가하는 솔루션은 모듈 범위가 아니라 패키지 범위여야 한다고 생각합니다. Go의 컴파일 단위는 모듈이 아니라 패키지이기 때문입니다.

따라서 가져올 파일 목록을 지정하기 위해 go.mod 를 사용하지 않습니다.

@dolmen 최종 결과가 자체 패키지에 있으면 범위 자체가 모듈이 됩니다.

@urandom 아니요, 범위는 생성된 패키지를 가져오는 패키지입니다. 그러나 어쨌든 나는 전체 생성된 패키지가 이 제안의 범위에 있다고 생각하지 않습니다.

@urandom 아니요, 범위는 생성된 패키지를 가져오는 패키지입니다. 그러나 어쨌든 나는 전체 생성된 패키지가 이 제안의 범위에 있다고 생각하지 않습니다.

이 제안이 어떻게 구현되든 상관없이 다양한 모듈 패키지가 최종 결과를 사용할 것이라는 점을 감안할 때 임베디드 대상에 대한 정의가 모듈 수준에서 지정되는 것이 합리적입니다. 임베디드 파일이 모듈 범위이고 매직 디렉토리에서 추가되는 Java 생태계에서도 이에 대한 선례가 이미 존재합니다.

또한 go.mod는 기존 프로그램을 손상시키지 않고 이러한 기능(매직 주석 또는 매직 디렉토리 없음)을 추가하는 가장 깔끔한 방법을 제공합니다.

여기에 아직 언급되지 않은 것이 있습니다. Go 소스 처리 도구(컴파일러, 정적 분석기)용 API는 런타임 API만큼 중요합니다. 이런 종류의 API는 생태계 성장에 도움이 되는 Go의 핵심 가치입니다( go/ast / go/format 및 go mod edit ).

이 API는 전처리기 도구(특히 go:generate 단계에서)에서 포함되어 참조를 생성하는 데 사용할 수 있는 파일 목록을 가져오는 데 사용할 수 있습니다.

특수 패키지의 경우 go.mod 파싱( go mod 도구) 또는 go/ast 파서에서 변경할 사항이 없습니다.

@고인돌

_"기호에 대한 기호 또는 값을 추가하는 솔루션은 모듈 범위가 아니라 패키지 범위여야 한다고 생각합니다. Go의 컴파일 단위는 모듈이 아니라 패키지이기 때문입니다. 따라서 go.mod를 사용하여 목록을 지정하지 않습니다. 가져올 파일입니다."_

모듈이란 무엇입니까? 모듈은 _" 단일 단위로 함께 버전이 지정된 관련 Go 패키지의 모음입니다 ."_ 따라서 모듈은 단일 패키지로 구성될 수 있고 단일 패키지는 전체 모듈이 될 수 있습니다.

따라서 go.mod 는 Go 팀이 특수 주석 및 매직 패키지보다 go.mod 를 채택한다고 가정할 때 가져올 파일 목록을 지정하는 올바른 위치입니다. Go 팀이 go.pkg 파일을 추가하기로 결정하기 전까지는 그렇습니다.

또한 Go 팀이 포함 파일을 지정하는 장소로 go.mod 를 수락했다면 파일을 포함하려는 사람은 embed 지침과 함께 go.mod 를 제공해야 하며 패키지 go.mod 파일이 있는 디렉토리로 표시되는 것은 포함된 파일을 포함하는 패키지입니다.

그러나 그것이 개발자가 원하는 것이 아니라면 다른 go.mod 파일을 만들고 포함된 파일을 포함하려는 패키지의 디렉토리에 넣어야 합니다.

이러한 제약 조건을 실행할 수 없는 합법적인 시나리오가 있습니까?

@mikeschinkel , 모듈은 _related_ 패키지 모음입니다. 그러나 해당 모듈 내의 다른 패키지의 전이 종속성(및 데이터!)을 가져오지 않고 모듈에서 하나의 패키지를 사용하는 것이 가능하고 합리적입니다!

데이터 파일은 일반적으로 모듈별이 아니라 패키지별 종속성이므로 이러한 종속성을 찾는 방법에 대한 정보는 별도의 모듈 수준 메타데이터로 저장되지 않고 패키지와 함께 배치되어야 합니다.

@bcmills

메시지의 '데이터 파일'을 '모듈'로 바꿀 수 있으며 여전히 유효할 것 같습니다.
자신의 특정 패키지에 대한 종속성으로 특정 모듈을 갖는 것은 매우 일반적입니다.
그러나 우리는 모두 go.mod에 넣습니다.

@urandom , go.mod 파일에 표시된 모듈의 모든 패키지가 최종 바이너리에 링크되는 것은 아닙니다. ( go.mod 파일에 종속성을 넣는 것은 해당 종속성을 프로그램에 연결하는 것과 _not_ 동일합니다.)

메타 포인트

이것은 많은 사람들이 관심을 갖고 있는 것이 분명하며, 상단에 있는 Brad의 원래 의견은 초기 스케치/출발점/행동 촉구라기보다 덜 완성된 제안서였습니다. 이 시점에서 이 특정 토론을 마무리하고 Brad와 아마도 다른 몇 사람이 세부 설계 문서에 대해 협력하도록 한 다음 해당 특정(아직 작성되지 않은) 문서에 대한 토론을 위해 새 문제를 시작하는 것이 합리적이라고 생각합니다. . 그렇게 하면 다소 거창한 대화가 된 내용에 초점을 맞추는 데 도움이 될 것 같습니다.

생각?

이 문서를 닫는 데 동의하는지 확신할 수 없지만 설계 문서가 있을 때까지 제안을 보류하고 의견을 잠시 잠글 수 있습니다. (사람들이 자신의 댓글이 중복되었는지 확인하기 위해 읽을 댓글이 너무 많기 때문에 이 시점에서 거의 모든 댓글이 중복됩니다...)

디자인 문서가 있으면 이 문서를 닫을 수 있습니다.

또는 이 항목을 닫고 #3035(댓글이 고정된 상태)를 다시 열어서 최소한 하나의 미해결 문제가 추적하도록 합니다.

닫기에 대해 이야기한 직후에 이렇게 해서 죄송하지만 @bcmills 댓글 직후와 내가 명확히 하기 전에 긴밀한 토론이 시작되었습니다.

"_그러나 해당 모듈 내에서 다른 패키지의 전이적 종속성(및 데이터!)을 가져오지 않고 모듈에서 하나의 패키지를 사용하는 것이 가능하고 합리적입니다."_

예, 분명히 _가능합니다._ 그러나 모든 모범 사례와 마찬가지로 데이터 패키지에 대한 모범 사례는 문제를 해결하는 모듈용 단일 패키지를 만드는 것일 수 있습니다. 루트에 go.mod 가 있고 데이터 패키지가 포함된 하위 디렉토리에 또 다른 go.mod 가 있으면 그렇게 됩니다.

여기에서 좋은 것은 go.mod 로 식별되며 본질적으로 목록에 포함되어 있는 임베드 파일을 지정하기에 완벽한 장소인 것으로 식별됩니다. 모듈의 구성 요소.

죄송합니다. 패키지는 모듈이 아니라 Go의 기본 개념입니다.
모듈은 단순히 하나의 단위로 버전이 지정되는 패키지 그룹입니다.
모듈은 개별 패키지의 의미 외에 추가 의미를 제공하지 않습니다.
그것은 그들의 단순함의 일부입니다.
여기서 우리가 하는 모든 것은 모듈이 아니라 패키지에 연결되어야 합니다.

이것이 어디로 가든지 수행되든 간에 (사용된 패턴뿐만 아니라) go list를 사용하여 임베드될 모든 자산 목록을 얻을 수 있는 방법이 있어야 합니다.

Brad와 다른 사람들이 공식적인 디자인 문서를 작성할 때까지 보류합니다.

특히 static 또는 embed 디렉토리를 사용하는 경우 특정 파일을 차단하는 것은 그리 어렵지 않습니다. 심볼릭 링크는 그것을 조금 복잡하게 할 수 있지만 현재 모듈 외부에 또는 GOPATH에 있는 경우 디렉토리를 포함하는 패키지 외부에 어떤 것도 포함하지 못하도록 방지할 수 있습니다.

나는 특히 코드로 컴파일되는 주석의 팬은 아니지만 컴파일에 영향을 미치는 의사 패키지도 약간 이상하다는 것을 알았습니다. 디렉토리 접근 방식이 사용되지 않는 경우에는 일종의 embed 최상위 선언을 언어에 실제로 빌드하는 것이 좀 더 합리적일 수 있습니다. import 와 유사하게 작동하지만 로컬 경로만 지원하며 할당할 이름이 필요합니다. 예를 들어,

embed ui "./ui/build"

func main() {
  file, err := ui.Open("version.txt")
  if err != nil {
    panic(err)
  }
  version, err = ioutil.ReadAll(file)
  if err != nil {
    panic(err)
  }
  file.Close()

  log.Printf("UI Version: %s\n", bytes.TrimSpace(version))
  http.ListenAndServe(":8080", http.EmbeddedDir(ui))
}

편집: @jayconrod, 당신이 저를 이겼습니다.

이것은 깨끗하고 읽을 수 있지만 go 팀이 새 키워드를 도입하고 싶어하는지 확신할 수 없습니다.

내가 기억하는 아이디어는 정적 데이터를 포함하는 "정적"과 같은 특별한 디렉토리 이름을 갖고 주석이 필요 없이 API를 통해 자동으로 사용할 수 있도록 하는 것이었습니다.

static 를 특별한 디렉토리 이름으로 사용하는 것은 약간 혼란스럽고 저는 assets 하고 싶습니다.
스레드에서 보지 못한 또 다른 아이디어는 assets 를 패키지로 가져오는 것을 허용하는 것입니다(예: import "example.com/internal/assets" . 노출된 API는 여전히 디자인이 필요하지만 적어도 특별한 주석이나 새로운 runtime/files 스타일 패키지보다 더 깔끔해 보입니다.

스레드에서 보지 못한 또 다른 아이디어는 자산을 패키지로 가져올 수 있다는 것입니다.

이것은 https://github.com/golang/go/issues/35950#issuecomment -562966654에서 제안되었습니다.

한 가지 복잡한 점은 유형 검사가 발생 하도록 하려면 언어 변경이 필요하거나

비슷한 생각이지만 static.go 디자인은 임의의 가져오기 경로를 데이터 패키지로 전환할 수 있는 반면 assets 디렉토리는 testdata , internal 또는 vendor 처럼 작동합니다 assets 가 가질 수 있는 가능한 요구 사항 중 하나는 Go 패키지를 포함하지 않거나 문서만 허용하는 것입니다.

이것은 파일을 가져오기 위한 runtime/files -thingy API와 결합될 수도 있습니다. 즉, 원시 import 를 사용하여 디렉토리 트리를 파일에 포함한 다음 액세스하기 위해 일부 런타임 패키지를 사용합니다. os.Open 일 수도 있지만 받아 들여지지 않을 것입니다.

shurcooL/vfsgen 함께 shurcooL/httpgzip 압축 해제 없이 콘텐츠를 제공할 수 있는 좋은 기능이 있습니다.

예

    rsp.Header().Set("Content-Type", "image/png")
    httpgzip.ServeContent(rsp, req, "", time.Time{}, file)

유사한 기능이 C++에 대해 제안되고 있습니다. std::embed :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r0.html
https://mobile.twitter.com/Cor3ntin/status/1208389050698215427

디자인에 영감을 주고 가능한 사용 사례를 수집하는 데 유용할 수 있습니다.

파티에 조금 늦었지만 아이디어가 있었습니다. 특별한 주석 대신, 고정된 특수 디렉토리(정적), 또는 go.mod를 확장하는 명백히 금지된 접근 방식: 패키지당 새 매니페스트 파일은 어떻습니까: go.res

• 파일 목록을 포함합니다. 경로나 글로브가 없고 현재 패키지 디렉토리의 이름만 있습니다. 필요한 경우 커밋하기 전에 glob에서 생성합니다.
  
  
  
  • __Edit__는 go 파일처럼 맨 위에 package mypackagename 행 하나만 필요할 수 있습니다. 또는 파일 이름에 패키지 이름을 포함할 수 있습니다(예: mypackagename.go.res). 개인적으로 package 헤더 라인이 더 좋습니다.
  
  
• "resource" 또는 "io/resource"라는 새로운 핵심 패키지. 현재 패키지에 포함된 리소스를 읽는 func Read(name string) (io.Reader, bool) 함수가 하나 이상 있습니다.
  
  
  
  • __Edit__ 핵심 패키지가 이런 식으로 작동하는지 확실하지 않습니다. 생성된 패키지 개인 함수여야 할 수도 있습니다(예: func readresource(name string) (io.Reader, bool) ).
  
  
• 하위 디렉토리에 리소스가 필요하면 go.res 파일과 하나 이상의 .go 파일을 추가하여 하위 디렉토리를 패키지로 만드십시오. go 파일은 하위 디렉토리 패키지의 리소스에 액세스하기 위해 고유한 공개 API를 내보냅니다. 다른 패키지의 리소스는 의도적으로 자동으로 내보내지지 않기 때문에 go 파일과 내보낸 API가 필요합니다. 이러한 방식으로 내보내는 방법을 사용자 지정할 수도 있습니다.
  
  
  
  • __Edit__ 또는 디렉토리 구조 및/또는 압축이 필요한 경우 tar 리소스를 사용합니다. 이것은 이미 컴파일이 필요한 웹팩 번들과 같은 것을 허용합니다(사전 압축의 이점이 있을 수 있음). 그들을 타르로 한 걸음 더 나아가게 하는 것은 간단합니다.
  
  
• __Edit__ 매니페스트가 필요하십니까? go.res 파일 자체를 리소스로 포함하기만 하면 됩니다. listresources 함수를 만들 필요조차 없습니다.

매우 간단합니다. 하나의 새로운 기능. 새 파일 하나. 경로가 없습니다. 압축 없음. 새로운 구문이 없습니다. 마법이 없습니다. 확장 가능. 리더를 통한 읽기 전용 액세스(그러나 향후 대체 액세스 패턴에 개방됨). 기존 패키지를 깨뜨릴 가능성은 거의 제로에 가깝습니다. 패키지가 핵심 구성인 상태를 유지합니다.

__Edit__ github 검색 language:go filename:go.res extension:res 후 go.res 사용하기에 꽤 안전한 파일 이름인 것 같습니다. go repos에는 일치하는 항목이 없고 non-go repos에는 몇 개만 있습니다.

@chris.ackermanm이라는 아이디어가 마음에 듭니다. 그러나 나는 조합을 선호합니다:

디렉토리 내의 네임스페이스를 지정하는 go.res 파일.

이것은 허용합니다

• 네임스페이스가 다른 한 다중 포함
• 이전에 파일을 모르고 목록을 생성해야 함

후자는 업데이트, 다른 옵션, 생각할 수 있는 모든 것으로 인해 레이아웃을 변경할 수 있는 webpack 등의 출력을 처리해야 합니다.

압축과 관련하여: 이진 크기가 폭발하지 않고 사용 코드에 투명해야 한다는 점에서 더 많은 기능이라고 생각합니다.

나중에 다음과 같은 재작성을 허용할 수 있습니다.

filename => stored-as.png

내 2¢

@sascha-andres 이 스레드의 톤은 매우 단순하고 마법이 없는 것 같습니다. 귀하의 제안에 대한 내 의견에 대한 수정 사항을 참조하십시오.

매핑이 마음에 들지 않습니다. 필요 없음. 그것은 어쨌든 별도의 패키지에서 자신의 읽기 기능을 노출함으로써 가능하며 이제 새로운 파일 구문 또는 파일당 파일보다 더 복잡한 것이 필요합니다.

안녕하세요

이 제안은 굉장합니다!

그리고 저는 자산에 대한 접근 방식을 가지고 있습니다. GNU bintools 이외의 다른 도구를 도입할 필요가 없습니다. 그것은 일종의 더럽지 만 지금은 저에게 잘 작동합니다. 도움이 될까해서 공유하려고 합니다.

내 접근 방식은 objcopy가 있는 elf/pe32 섹션에 내 자산(tar&gz로 압축)을 포함하고 필요할 때 zip과 함께 debug/elf 및 debug/pe32 패키지를 통해 읽는 것입니다. 내가 기억해야 할 것은 기존 섹션을 건드리지 않는 것입니다. 모든 자산은 변경할 수 없으며 코드는 콘텐츠를 읽고 메모리에서 처리합니다.

저는 언어 디자인이나 컴파일러 디자인에 대한 경험이 거의 없습니다. 그래서 위에서 설명한 접근 방식을 사용하고 .goassets 또는 이와 유사한 것을 섹션 이름으로 사용합니다. 압축을 선택 사항으로 만드십시오.

내 접근 방식은 objcopy가 있는 elf/pe32 섹션에 내 자산(tar&gz로 압축)을 포함하고 필요할 때 zip과 함께 debug/elf 및 debug/pe32 패키지를 통해 읽는 것입니다. 내가 기억해야 할 것은 기존 섹션을 건드리지 않는 것입니다. 모든 자산은 변경할 수 없으며 코드는 콘텐츠를 읽고 메모리에서 처리합니다.

elf / pe32 에서 작동하는 것처럼 들리지만 mach-o / plan9 어떻습니까?

또 다른 문제는 실행 파일의 파일 핸들을 여는 데 의존한다는 것입니다. 실행 파일이 덮어쓰기/업데이트/삭제된 경우 합법적인 문제인지 예상치 못한 기능인지 확실하지 않은 다른 데이터가 반환됩니다.

디버그/macho를 사용하여 약간의 시도가 있었지만 이 교차 플랫폼에서 작동하는 방법을 볼 수 없습니다. macOS에서 빌드 중이고 설치된 GNU binutils가 mach-o-x86-64 를 손상시킨 것 같습니다. mach-o 구조에 대한 이해가 부족하고 objcopy 본 이후로 너무 오래되었을 수 있음).

또 다른 문제는 실행 파일에서 파일 핸들을 여는 데 의존한다는 것입니다.

프로그램 로더가 리소스 섹션을 메모리로 로드(또는 로드할 수 있음)하므로 디버그 패키지를 사용할 필요가 없습니다. 데이터에 액세스하려면 가치가 있는 것보다 훨씬 더 많은 개체 파일을 수정해야 합니다.

예를 들어 Java 가 작동하는 방식을 따르십시오. 나는 큰 일을 요구하지만 다음과 같은 내용이 있습니다.

• go.res 파일을 생성하거나 리소스가 있는 디렉토리를 가리키도록 go.mod 수정
• 이 디렉토리의 모든 파일은 자동으로 포함되며 최종 실행 파일에는 컴파일러에 의한 예외 가
• 언어는 이러한 리소스에 액세스하기 위한 경로와 유사한 API를 제공합니다.

압축 등은 이 리소스 번들링 범위를 벗어나야 하며 필요한 경우 // go:generate 스크립트까지 가능합니다.

누구든지 markbates/pkger를 보셨습니까 ? go.mod 를 현재 작업 디렉토리로 사용하는 매우 간단한 솔루션입니다. index.html 가 포함되어 있다고 가정하면 pkger.Open("/index.html") 됩니다. 프로젝트에 static/ 디렉토리를 하드코딩하는 것보다 이것이 더 나은 아이디어라고 생각합니다.

내가 볼 수 있는 한 Go에는 프로젝트에 대한 중요한 구조 요구 사항이 없다는 점도 언급할 가치가 있습니다. go.mod 는 파일일 뿐이고 vendor/ 사용하는 사람은 많지 않습니다. 나는 개인적으로 static/ 디렉토리가 좋을 것이라고 생각하지 않습니다.

기존 ldflags 링크 플래그 -X importpath.name=value 를 통해 (제한적이긴 하지만) 데이터를 빌드에 주입하는 방법이 이미 있으므로 해당 코드 경로를 조정하여 -X importpath.name=@filename 주입할 수 있습니까? 외부 임의 데이터?

이것이 원래 문제의 명시된 목표를 모두 다루지는 않는다는 것을 알고 있지만 기존 -X 기능의 확장으로서 합리적인 단계로 보입니까?

(그리고 그것이 효과가 있다면 ldflags -X 값을 지정하는 더 깔끔한 방법으로 go.mod 구문을 확장하는 것이 합리적인 다음 단계입니까?)

매우 흥미로운 아이디어지만 보안에 미치는 영향이 걱정됩니다.

-X 'pkg.BuildVersion=$(git rev-parse HEAD)' 를 하는 것은 꽤 흔한 일이지만 go.mod 가 임의의 명령을 실행하게 하고 싶지는 않겠죠? (go generate는 할 수 있지만 일반적으로 다운로드한 OSS 패키지에 대해 실행하는 것은 아닙니다.) go.mod가 이를 처리할 수 없으면 결국 주요 사용 사례가 누락되므로 ldflags는 여전히 매우 일반적입니다.

그런 다음 @filename 가 /etc/passwd 또는 무엇에 대한 심볼릭 링크가 아닌지 확인하는 다른 문제가 있습니다.

링커를 사용하면 WASM 및 링커를 사용하지 않는 다른 대상에 대한 지원이 배제됩니다.

여기에서 논의한 내용을 바탕으로 고안 했으며 각각의 방식 중 가장 좋은 방식을 선택했습니다. 초안 디자인 문서, 비디오 및 코드를 게시했습니다(아래 링크). 이 문제에 대한 의견 대신 Reddit Q&A를 사용하여 이 특정 초안 디자인에 대한 의견을 제출하십시오. Reddit 스레드 및 GitHub보다 더 나은 토론 규모. 감사 해요!

동영상: https://golang.org/s/draft-embed-video
디자인: https://golang.org/s/draft-embed-design
Q&A: https://golang.org/s/draft-embed-reddit
코드: https://golang.org/s/draft-embed-code

@rsc 제 생각에 go:embed 제안은 컴파일 시간에 _universal_ 샌드박스 처리된 Go 코드 실행을 제공하는 것보다 열등합니다. 여기에는 파일 읽기와 읽은 데이터를 런타임에 사용하기에 가장 적합한 _최적 형식_으로 변환하는 작업이 포함됩니다.

@atomsymbol 그것은 이 문제의 범위를 벗어난 것처럼 들립니다.

@atomsymbol 그것은 이 문제의 범위를 벗어난 것처럼 들립니다.

나는 그것을 알고 있다.

제안서를 읽고 코드를 스캔했지만 이에 대한 답을 찾을 수 없었습니다. 이 임베딩 방식에 디스크의 파일(~os.Stat)에 대한 정보가 포함됩니까? 아니면 이 타임스탬프가 빌드 시간으로 재설정됩니까? 어느 쪽이든, 이들은 다양한 장소에서 사용되는 유용한 조각 정보입니다. 예를 들어 이를 기반으로 변경되지 않은 자산에 대해 304를 보낼 수 있습니다.

감사 해요!

편집: reddit 스레드에서 찾았습니다.

모든 포함된 파일에 대한 수정 시간은 귀하가 나열한 재현성 문제와 정확히 일치하는 0시간입니다. (모듈은 같은 이유로 수정 시간도 기록하지 않습니다.)

https://old.reddit.com/r/golang/comments/hv96ny/qa_goembed_draft_design/fytj7my/

어느 쪽이든, 이들은 다양한 장소에서 사용되는 유용한 조각 정보입니다. 예를 들어 이를 기반으로 변경되지 않은 자산에 대해 304를 보낼 수 있습니다.

파일 데이터 해시를 기반으로 하는 ETag 헤더는 날짜에 대해 알 필요 없이 해당 문제를 해결할 수 있습니다. 그러나 그것은 http.HandlerFS 또는 작동할 수 있고 리소스를 낭비하지 않으려면 파일당 한 번만 수행되어야 하는 것으로 알려져야 합니다.

그러나 그것은 http.HandlerFS 또는 작동할 수 있고 리소스를 낭비하지 않으려면 파일당 한 번만 수행되어야 하는 것으로 알려져야 합니다.

http.HandlerFS는 fs.FS가 변경 불가능하다는 것을 어떻게 알 수 있습니까? IsImmutable() bool 옵션 인터페이스가 있어야 합니까?

http.HandlerFS는 fs.FS가 변경 불가능하다는 것을 어떻게 알 수 있습니까? IsImmutable() bool 옵션 인터페이스가 있어야 합니까?

나는 이러한 것들의 디자이너가 아니기 때문에 구현 세부 사항에 들어가기를 원하지 않지만 http.HandlerFS는 그것이 embed.FS 유형인지 확인하고 특별한 경우로 조치할 수 있습니다. 지금 바로 FS API를 확장하십시오. HandlerFS에 옵션 인수가 있을 수도 있습니다. 이는 파일 시스템을 변경할 수 없는 것으로 처리하도록 지시하기 위한 것입니다. 또한 이것이 응용 프로그램 시작 시 수행되고 모든 ctime/mtime의 값이 0인 경우 handlerFS는 해당 정보를 사용하여 파일이 변경되지 않았음을 "알 수 있지만" mtime이 없거나 비활성화된 파일 시스템도 있습니다. 문제도 있을 수 있습니다.

나는 이 문제에 대한 댓글을 보지 않았다.

@atomsymbol 다시 오신 것을 환영합니다! 여기 댓글 다시 보니 반갑네요.
나는 원칙적으로 샌드박싱이 있다면 많은 일이 더 쉬울 것이라는 데 동의합니다.
반면에 빌드가 완료되지 않을 수도 있습니다.
어쨌든 오늘날 우리에게는 그런 종류의 샌드박싱이 없습니다. :-)

@kokes 자세한 내용은 잘 모르겠습니다.
그러나 HTTP를 통해 embed.Files를 제공하면 기본적으로 ETag가 올바르게 제공됩니다.

나는 7월에 다시 게시된 디자인 초안을 수락하기 위해 #41191을 제출했습니다.
나는 그 문제로 대체되어 이 문제를 닫을 것입니다.
여기에서 훌륭한 예비 토론을 해주셔서 감사합니다.