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アプローチは、別のレベルの複雑さももたらします。 コードをタイプチェックするためにも、魔法のコメントを解析する必要があります。 「埋め込みパッケージ」アプローチは、静的分析に適しているようです。

（ここで大声で黙想するだけです。）

@opennota 、

http.FileServerを使用してHTTPで埋め込みアセットを提供する機能が必要になります。

はい、上記の最初のリンクは私が作成したパッケージ（ 2011年にGo 1より前）であり、現在も使用されており、http.FileServerの使用をサポートしています： https ：//godoc.org/perkeep.org/pkg/fileembed#Files.Open

@cespare 、

// go：embedアプローチは、別のレベルの複雑さももたらします。 コードをタイプチェックするためにも、魔法のコメントを解析する必要があります。 「埋め込みパッケージ」アプローチは、静的分析に適しているようです。

はい、良い点です。 これは、パッケージを使用するための非常に強力な議論です。 また、cmd / goのドキュメントの奥深くではなく、通常のgodocを使用してすべてをドキュメント化できるため、読みやすく、ドキュメント化が容易になります。

@ bradfitz-このhttps://github.com/golang/go/issues/3035を閉じ

@agnivade 、それを見つけてくれてありがとう！ 覚えていると思ったのですが見つかりませんでした。 とりあえず開いたままにして、他の人の考えを見てみましょう。

マジックパッケージを使用する場合は、エクスポートされていない型のトリックを使用して、呼び出し元がコンパイル時の定数を引数として渡すようにすることができます： https ：

（これはここで参照されている戦略です：https：//groups.google.com/forum/#！topic / golang-nuts / RDA9Hag8RZw / discussion）

私が懸念していることの1つは、インビビッドまたはすべてのアセットが大きすぎてメモリに収まらないことをどのように処理するか、アクセス時間とメモリフットプリントの優先順位付け、または中間的な実装のどちらかを選択するビルドタグまたはファイルごとのアクセスオプションがあるかどうかです。

私がその問題を解決した方法（もちろん私も自分の実装を持っているので:)）は、すべての埋め込みアセットを提供するhttp.FileSystem実装を提供することです。 そうすれば、タイプチェッカーをなだめるために魔法のコメントに頼る必要はありません。アセットはhttpで簡単に提供でき、フォールバック実装はコードを変更せずに開発目的（http.Dir）で提供でき、最終的にはhttp.FileSystemは、ファイルの読み取りだけでなく、ディレクトリの一覧表示もかなりカバーしているため、実装は非常に用途が広いです。

プレーンテキストファイルを介してすべてのグロブを指定する方がおそらく簡単ですが、マジックコメントなどを使用して、埋め込む必要があるものを指定することもできます。

@AlexRouSgこの提案は、最終的な実行可能ファイルに直接含めるのに適切なファイルのみを対象としています。 大きすぎてメモリに収まらないファイルにこれを使用することは適切ではありません。 その場合を処理するためにこのツールを複雑にする理由はありません。 その場合は、このツールを使用しないでください。

@ ianlancetaylor 、 @ AlexRouSgが行っていた[]byteとして提供すること（ページングできない、書き込み可能な可能性のあるメモリ）と、ELFセクションの読み取り専用のオンデマンドビューを提供することの違いだと思います。通常、 *io.SectionReaderを返すOpen呼び出しを介するように、（実行可能ファイル内の）ディスク上に存在します。 （ http.Fileまたはhttp.FileSystemをcmd / goまたはruntimeに焼き付けたくありません... net / httpはアダプターを提供できます。）

@bradfitz両方のhttp.File自体は、 httpパッケージへの技術的な依存関係のないインターフェイスです。 Stat ReaddirメソッドとOpenメソッドがそのインターフェイスに準拠する実装を提供することは良い考えかもしれません。

@urandom 、ただし、「http.File」名（https://play.golang.org/p/-r3KjG1Gp-8）を参照せずに、http.FileSystemを実装することはできませんでした。

@robpikeと私は、この数年前（提案プロセスが行われる前）に行うための提案について話し合いましたが、何もすることに戻ることはありませんでした。 私たちがそれをやり終えなかったことは何年もの間私を悩ませてきました。 私が覚えているアイデアは、静的データを含む「static」のような特別なディレクトリ名を設定し、注釈を必要とせずにAPIを介して自動的に利用できるようにすることでした。

「圧縮vsない」ノブの複雑さについては確信が持てません。 そうすれば、人々は私たちにどの圧縮、圧縮レベルなどの制御を追加することを望んでいるでしょう。 追加する必要があるのは、プレーンバイトのファイルを埋め込む機能だけです。 ユーザーが圧縮データをそのファイルに保存したい場合は、詳細はユーザー次第であり、Go側にAPIはまったく必要ありません。

いくつかの考え：

• 埋め込みを行うモジュールの外部にファイルを埋め込むことはできません。 ファイルを作成するときは、ファイルがモジュールzipファイルの一部であることを確認する必要があります。これは、シンボリックリンクや大文字と小文字の競合などがないことも意味します。合計を壊さずにzipファイルを生成するアルゴリズムを変更することはできません。
• 同じディレクトリ（ //go:embedコメントが使用されている場合）または特定のサブディレクトリ（ staticが使用されている場合）に埋め込むように制限する方が簡単だと思います。 これにより、パッケージと埋め込みファイルの関係を非常に簡単に理解できるようになります。

いずれにせよ、これは/etc/shadowまたは.git埋め込みをブロックします。 どちらもモジュールzipに含めることはできません。

一般的に、goコマンドの範囲を拡大しすぎるのではないかと心配しています。 ただし、この問題に対する解決策が非常に多いという事実は、おそらく1つの公式な解決策があるはずであることを意味します。

私は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っぽいインターフェースです。

典型的なケースは、埋め込まれたデータを不変にしたい場合です。 ただし、 []byte （ io.Reader 、 io.SectionReaderなどを含む）を公開するすべてのインターフェイスは、（1）コピーを作成するか、（2）可変性を許可するか、（3） []byteであるにもかかわらず、不変である。 データをstringとして公開することでそれを解決できますが、APIを犠牲にして、埋め込みファイルを消費する多くのコードが最終的に何らかの方法でバイトスライスを必要とするため、とにかくコピーが必要になることがよくあります。

ルート（3）をお勧めします： []byteであるにもかかわらず不変である。 バッキング配列に読み取り専用シンボルを使用することで、これを安価に実施できます。 これにより、 []byteおよびstringと同じデータを安全に公開することもできます。 データを変更しようとすると失敗します。 コンパイラーは不変性を利用できませんが、それはそれほど大きな損失ではありません。 これは、ツールチェーンのサポートがテーブルにもたらすことができるものであり、（私が知る限り）既存のcodegenパッケージのどれもしません。

（サードパーティのcodegenパッケージは、読み取り専用としてマークされたDATAシンボルを含む汎用アセンブリファイルを生成し、それらのシンボルをstring形式で公開する短いアーチ固有のアセンブリファイルを生成することでこれを行うことができます。 sがおよび[]byte sの。私が書いたCL 163747を特に念頭に置いて、このユースケースで、決して任意のコード生成パッケージに統合する暇が。）

不変性の観点からあなたが何について話しているのかわかりません。 io.Readerすでに不変性を強制しています。 それが全体のポイントです。 Read(buf)を呼び出すと、_you_が提供したバッファにデータがコピーされます。 その後buf変更しても、 io.Readerの内部には影響しません。

@DeedleFakeに同意します。 魔法の[]byte配列バッキングでゲームをしたくありません。 バイナリからユーザー提供のバッファにコピーしても問題ありません。

ここでもう1つの問題があります。DTraceソースコード（埋め込み）を使用する別のプロジェクトがあります。 これは、\ nと\ r \ nの違いに敏感です。 （これがDTraceの馬鹿げたことであるかどうかを議論することができます-それは重要なことではなく、今日の状況です。）

バックティック文字列がソースでの表示方法に関係なく両方を\ nとして扱うことは非常に便利であり、DTraceを埋め込むためにgo-generateでこれに依存しています。

したがって、goコマンドに埋め込みファイルが追加されている場合は、CR / CRLFの処理を変更するオプションが非常に役立つ可能性があることをお勧めします。特に、デフォルトの行末が可能なさまざまなシステムで開発している場合はそうです。落とし穴。

圧縮の場合と同様に、「ファイルバイトをバイナリにコピーする」ことで停止したいと思います。 CR / CRLF正規化、Unicode正規化、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にコメントを認識させ、グロブを示すBazelルールを書き出すことを意味します。次に、ビルドに含める追加のファイルを生成するためのツール（go tool embedgenなど）を公開する必要があります（goコマンドはこれを自動的に行い、実際に余分なファイルを表示することはありません）。 それは十分に簡単に思えます。

さまざまな変更でうまくいかない場合、それはこの新しい機能を使用することに反対する議論です。 それは私にとってストッパーではありません-私は今までと同じようにgogenerateを使用できますが、それは私が新機能の恩恵を受けることができないことを意味します。

一般的な変更に関しては、誰かがインターフェイスの実装を提供するソリューションを想像できます（一方にReader（）のようなもの、もう一方にファイルを受信するもの）。おそらくio.Readerでインスタンス化されます。ファイル自体から）-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モードでは実際には役に立ちません。）

「圧縮vsない」ノブの複雑さについては確信が持てません。 そうすれば、人々は私たちにどの圧縮、圧縮レベルなどの制御を追加することを望んでいるでしょう。 追加する必要があるのは、プレーンバイトのファイルを埋め込む機能だけです。

シンプルさへの意欲に感謝しますが、ユーザーのニーズを満たしていることも確認する必要があります。

https://tech.townsourced.com/post/embedding-static-files-in-go/#comparisonにリストされている14個のツールのうち12個は圧縮をサポートしており、これはかなり一般的な要件であることを示しています。

goの外でビルド前のステップとして圧縮を行うことができるのは事実ですが、それでも1）圧縮を行うためのツール2）ある種のassets.zipブロブをvcsにチェックインする3）おそらくユーティリティが必要です圧縮を元に戻すための埋め込みAPI周辺のライブラリ。 その時点で、どのようなメリットがあるのか​​はまったく不明です。

最初の提案に記載された3つの目標は次のとおりです。

• 生成されたファイルをチェックインしないでください
• インストールを実行/ビルドを実行して自動的に埋め込みを実行します
• 必要に応じて、圧縮されたアセットをバイナリに保存します

これらの2番目を「埋め込みに別のツールを必要としない」と読んだ場合、圧縮ファイルを直接的または間接的にサポートしないと、これら3つの目標すべてを達成できません。

これはパッケージレベルである必要がありますか？ ほとんどの場合、1つのモジュール= 1つのプロジェクトであるため、モジュールレベルの粒度は優れているようです。

このディレクトリにはGoコード†が含まれていないので、 _staticようなものでしょうか？

†または、そうである場合は、コンパイルされるGoコードとしてではなく、名前が「.go」で終わる任意のバイトとして扱われます。

それが1つの特別なディレクトリである場合、ロジックはそのディレクトリツリー内のすべてのものを丸呑みにする可能性があります。 魔法の埋め込みパッケージを使用すると、 embed.Open("img/logo.svg")ような操作を実行して、アセットツリーのサブディレクトリにあるファイルを開くことができます。

文字列で十分なようです。 それらは簡単に[]byteコピーしたり、 Reader変換したりできます。 コード生成またはライブラリを使用して、より洗練されたAPIを提供し、 init間に処理を行うことができます。 これには、解凍またはhttp.FileSystem作成が含まれる可能性があります。

Windowsには、アセットを埋め込むための特別な形式はありません。 Windows実行可能ファイルをビルドするときにそれを使用する必要がありますか？ もしそうなら、それは提供できる操作の種類に影響を及ぼしますか？

gitfsを忘れないでください😂

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

go build / linkの一部にできない理由はありますか...例： go build -embed example=./path/example.txtと、それにアクセスできるパッケージ（例： go:embedを使用する代わりにembed.File("example") ） go:embed ？

ただし、コードにはそのためのスタブが必要です

@egonelbre go build -embedの問題は、すべてのユーザーがそれを適切に使用する必要があるということです。 これは完全に透過的で自動である必要があります。 既存のgo installまたはgo getコマンドは、正しいことをやめることはできません。

@bradfitzPackrよりもhttps://github.com/markbates/pkgerをお勧めし

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（上記でリンク）にはこのようなモードがあり、1つの大きなバイナリをリンクする必要がない増分開発をスピードアップするのに便利です。

mjibson / escもこれを行います。これは、Webアプリを開発する際の生活の質の大幅な向上です。 リンク時間を節約できるだけでなく、Webアプリの実装によっては、アプリケーションを再起動する必要がなくなります。これには、かなりの時間がかかるか、変更をテストするために追加の手順を繰り返す必要があります。

現在の状況に関する問題：

• go：generateベースのソリューションを使用すると、各ファイルの2番目の（そして少し大きい）コピーで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ファイルを生成する場合、すでにgogetフローを中断する可能性があります

そのための通常のフローと、私が一般的に使用しているフローは、少し慣れが必要ですが、 go generate開発終了ツールとして完全に使用し、次のファイルをコミットすることだと思います。生成します。

@bradfitz http.FileSystem自体を実装する必要はありません。 実装がhttp.Fileを実装する型を提供する場合、stdlib httpパッケージを含め、 Open関数のラッパーを提供して、型をhttp.Fileに変換することは、誰にとっても簡単です。 http.FileSystem

ただし、@ andreynering //go:generateと//go:embedは大きく異なります。 このメカニズムは、任意のコードを実行しないため、ビルド時にシームレスに発生する可能性があります。 これは、cgoがgo build一部としてコードを生成する方法と似ていると思います。

「圧縮vsない」ノブの複雑さについては確信が持てません。 そうすれば、人々は私たちにどの圧縮、圧縮レベルなどの制御を追加することを望んでいるでしょう。 追加する必要があるのは、プレーンバイトのファイルを埋め込む機能だけです。

シンプルさへの意欲に感謝しますが、ユーザーのニーズを満たしていることも確認する必要があります。

https://tech.townsourced.com/post/embedding-static-files-in-go/#comparisonにリストされている14個のツールのうち12個は圧縮をサポートしており、これはかなり一般的な要件であることを示しています。

私はこの推論に同意するかどうかわかりません。

他のライブラリによって行われる圧縮は、この提案に追加することとは異なり、代替は一般的にビルド時ではなくビルド前に生成されるため、後続のビルドのパフォーマンスが低下することはありません。

ビルド時間が短いことは、他の言語よりも優れていることによる明らかな付加価値であり、圧縮はCPU時間をトレードしてストレージ/転送フットプリントを削減します。 多くのGoパッケージがgo build圧縮の実行を開始した場合、ビルド中にアセットをコピーするだけで追加される時間よりもさらに多くのビルド時間が追加されます。 他の人が圧縮を行っているため、圧縮を追加することに懐疑的です。 初期設計が設計上、つまり圧縮のサポートを追加する将来の拡張を妨げない限り、それをそこに置くことは、不必要なヘッジのように思われるかもしれないので、そこに入れます。

ファイルの埋め込みが圧縮なしでは役に立たないというわけではありません。圧縮は、バイナリサイズをおそらく100MBから50MBに減らすのに便利です。これは素晴らしいことですが、私が考えることができるほとんどのアプリケーションの機能の明確な取引を妨げるものでもありません。 。 特に、「重い」アセットのほとんどが、すでにかなり十分に圧縮されているJPEGやPNGなどのファイルである場合はそうではありません。

今のところ圧縮を避けて、実際に多くの人が見逃している場合は追加するのはどうですか？ （そして、過度のコストなしで行うことができます）

上記の@sakjurのコメントに追加するには：圧縮は私に直交しているようです。 私は通常、アセットだけでなく、バ​​イナリ全体またはリリースアーカイブ全体を圧縮したいと考えています。 特に、GoのGoバイナリが、アセットなしで数十メガバイトに簡単に入る可能性がある場合。

@mvdan私の懸念の1つは、埋め込みが他の前処理（縮小、タイプスクリプトのコンパイル、データ圧縮、画像のクランチ、画像のサイズ変更、スプライトシート）と一緒に行われることをよく見たことです。 唯一の例外は、 html/templateのみを使用するWebサイトです。 したがって、最終的には、とにかく何らかの「Makefile」を使用したり、前処理されたコンテンツをアップロードしたりする可能性があります。 その意味で、コマンドラインフラグはコメント以外のツールでうまく機能すると思います。

私の懸念の1つは、埋め込みが他の前処理（縮小、タイプスクリプトのコンパイル、データ圧縮、画像のクランチ、画像のサイズ変更、スプライトシート）と一緒に行われることをよく見たことです。 唯一の例外は、html / templateのみを使用するWebサイトです。

おかげで、それは有用なデータポイントです。 おそらく、圧縮の必要性は見た目ほど一般的ではありません。 もしそうなら、私はそれを省くことは理にかなっていることに同意します。

ファイルの埋め込みが圧縮なしでは役に立たないというわけではありません。圧縮は、バイナリサイズをおそらく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でサポートされていない機能がすでにあります（チェックサムデータベースを使用したセキュリティ、プロキシサーバーを介した依存関係のダウンロード、セマンティックインポートのバージョン管理など）

@bcmillsが述べたように、go.modファイルに静的ディレクトリ名を含めることは、<= go1.14句を持つgo.modファイルでこの機能を自動的にオフにできるため、Go1.15でこの機能を導入するための優れた方法です。

とはいえ、これは、ユーザーが静的ディレクトリパスを手動で書き込む必要があることも意味します。

ベンダーディレクトリと_test.goの規則は、Goとこれら2つの機能の操作をはるかに簡単にした方法の良い例だと思います。

ベンダーのディレクトリ名をカスタマイズするオプションを要求したり、 _test.go規則を別のものに変更したりする機能を持っている人はあまりいません。 しかし、Goが_test.go機能を導入しない場合、Goでのテストは今日では大きく異なって見えます。

したがって、 staticよりも一般的でない名前を使用すると、衝突が発生しない可能性が高くなります。したがって、従来のディレクトリ（vendorや_test.goと同様）を使用すると、魔法のコメントよりもユーザーエクスペリエンスが向上する可能性があります。

衝突が少ない可能性のある名前の例：

• _embed - _test.go規則に従います
• go_binary_assets
• .gobinは.gitの規則に従います
• runtime_files - runtime.Files構造体と一致するように

最後に、 vendorディレクトリがGo1.5で追加されました。 すっごく、今新しいコンベンションを追加するのはそれほど悪くないのでしょうか？ 😅

mmap-readonly []byteを公​​開する必要があると思います。 必要に応じてOSによってページインされた、実行可能ファイルからのページへの生のアクセス。 その上に、 bytes.NewReaderだけで他のすべてを提供できます。

これが何らかの理由で受け入れられない場合は、 ReadSeekerだけでなくReaderAtを提供してください。 後者は前者から構築するのは簡単ですが、他の方法はそれほど良くありません。単一のオフセットを保護するためにミューテックスが必要になり、パフォーマンスが台無しになります。

ファイルの埋め込みが圧縮なしでは役に立たないというわけではありません。圧縮は、バイナリサイズをおそらく100MBから50MBに減らすのに便利です。これは素晴らしいことですが、私が考えることができるほとんどのアプリケーションの機能の明確な取引を妨げるものでもありません。 。

バイナリサイズは、多くのGo開発者にとって大きな問題です（＃6853）。 GoはDWARFデバッグ情報を圧縮して、特にバイナリサイズを削減しますが、これにはリンク時間がかかります（＃11799、＃26074）。 バイナリサイズを半分に減らす簡単な方法があれば、開発者はその機会に飛躍すると思います（ただし、ここでの利益がほぼそれほど重要になるとは思えません）。

それは間違いなく公正な点であり、私の議論がファイルサイズに関する不注意を支持する議論としてどのように見られるかを見ることができます。 それは私の意図ではありませんでした。 私のポイントは、圧縮なしでこの機能を出荷することと一致しており、それでも一部の人にとっては有用であり、長期的に適切に感じる方法で圧縮を適切に追加する方法に関する有用なフィードバックと洞察を提供できます。 アセットは、デバッグ情報が実行されそうにない方法で膨らむ可能性があり、実装によって簡単に実行できる場合は、他のユーザーによってインストール/インポートされたパッケージの開発者がビルドのパフォーマンスを不必要に低下させることが容易になります。

もう1つのオプションは、アセットの圧縮をビルドフラグにし、ビルドサイズと時間の間の妥協点を開発者ではなくビルダーに任せることです。 これにより、圧縮が価値があるかどうかを判断できるバイナリのエンドユーザーに決定が近づきます。 音、これは開発と本番の違いで表面積が増えるリスクがあるので、他の何よりも明確な方法ではなく、私が主張したいと思うものでもありません。

私の現在のアセット埋め込みツールは、 -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ベースのソリューションを使用すると、各ファイルの2番目の（そして少し大きい）コピーでgit履歴が肥大化します。

うわー。 どうでも。 ごめん。

ファイルの埋め込みが圧縮なしでは役に立たないというわけではありません。圧縮は、バイナリサイズをおそらく100MBから50MBに減らすのに便利です。これは素晴らしいことですが、私が考えることができるほとんどのアプリケーションの機能の明確な取引を妨げるものでもありません。 。

バイナリサイズは、多くのGo開発者にとって大きな問題です（＃6853）。 GoはDWARFデバッグ情報を圧縮して、特にバイナリサイズを削減しますが、これにはリンク時間がかかります（＃11799、＃26074）。 バイナリサイズを半分に減らす簡単な方法があれば、開発者はその機会に飛躍すると思います（ただし、ここでの利益がほぼそれほど重要になるとは思えません）。

それが必要な場合、人々は圧縮データをコミットして埋め込むことができ、 runtime.Embedとエンドコンシューマーの間にインラインで解凍を行うレイヤーを提供するパッケージがあります。

そして、今から1、2年後には、圧縮の追加に関する新しい問題が発生し、それを並べ替えることができます。

私がgoembedを書いたとき、私はこれを15の競合する標準の1つとして言います:)

@ tv42は書いた：

mmap-readonly []byteを公​​開する必要があると思います。 必要に応じてOSによってページインされた、実行可能ファイルからのページへの生のアクセス。

このコメントは簡単に見落とされ、驚くほど価値があります。

@ tv42 、

mmap-readonly [] byteを公開する必要があると思います。 必要に応じてOSによってページインされた、実行可能ファイルからのページへの生のアクセス。 その上に、bytes.NewReaderだけで他のすべてを提供できます。

すでに読み取り専用になっているタイプはstringです。 また、 io.ReaderAtとは異なり、サイズを提供し、標準ライブラリに依存しません。 それはおそらく私たちが公開したいものです。

すでに読み取り専用になっているタイプはstringです。

しかし、 Writeなどのエコシステム全体は[]byteます。 それは単純な実用主義です。 io.Writer.Writeドキュメントが言っている以上に、読み取り専用プロパティが問題になることはないと思います。

書き込みは、一時的であっても、スライスデータを変更してはなりません。

もう1つの潜在的な欠点は、ディレクトリにgo:generateを埋め込むときに、 git diffの出力をチェックして、誤ってファイルが存在するかどうかを確認できることです。 この提案で-？ おそらく、goコマンドはそれが埋め込んでいるファイルのリストを出力するでしょうか？

@ tv42

しかし、Writeなどのエコシステム全体は[]バイトで機能します。

ただし、 html/templateは文字列で機能します。

すでに-ldflags-Xを使用していくつかの文字列を設定できます（gitバージョン、コンパイル時、サーバー、ユーザーなどの設定に役立ちます）。このメカニズムを拡張して、文字列の代わりにio.Readersを設定できますか？

@bradfitzテキストではないデータに対しても、ここで文字列を使用することを提案していますか？ アイコンや小さな画像などの小さなバイナリファイルを埋め込むのは一般的です。

@ tv42 Writeとおっしゃいましたが、 Readを意味していると思います。 あなたは変えることができますstringにio.ReaderAt使用してstrings.NewReader 、その文字列を使用すると、そこに障壁のように見えるしていませんが。

@andreynering stringは、任意のバイトシーケンスを保持できます。

stringは、任意のバイトシーケンスを保持できます。

ええ、でもその主な目的はテキストを保持することであり、任意のデータを保持することではありません。 これは、特に経験の浅いGo開発者にとって、少し混乱を引き起こす可能性があると思います。

しかし、私は完全にその考えを思いつきました。 明確にしていただきありがとうございます。

@ianlancetaylor

Readは、渡されたスライスを変更することになっています。 Writeは変更されません。 したがって、 Writeドキュメントには、これは許可されていないと記載されています。 ユーザーが返された[]byte書き込みをしてはならないことを文書化する以外に、何も必要とされていません。

strings.Readerが存在するからといって、 io.WriteStringが文字列を書く効率的な実装を見つけるとは限りません。 たとえば、 TCPConnはWriteStringがありません。

ソケットに書き込むためだけにすべてのデータを強制的にコピーするためだけに、このような新機能をGoに含めるのは嫌です。

また、一般的な仮定では、文字列は人間が印刷できるものであり、 []byteは印刷できないことがよくあります。 JPEGを文字列に入れると、端末がめちゃくちゃになります。

@opennota

ただし、html / templateは文字列で機能します。

ええ、それは奇妙なものです、それはリーダーとしてではなくパス名でファイルをとるだけです。 2つの応答：

1. 埋め込まれたデータがBytes() []byteとString() string両方のメソッドを持つことができなかった理由はありません。

2. うまくいけば、リクエストごとにテンプレートを解析しているわけではありません。 一方、実際には、JPEGのデータを要求するすべての要求に対してTCPソケットに送信する必要があります。

@ tv42必要に応じて、 WriteStringメソッドを追加できます。

この機能の最も一般的な使用法は、変更されていないデータを書き込むことではないと思います。そのため、その場合に最適化する必要はないと思います。

この機能の最も一般的な使用法は、変更されていないデータを書き込むことではないと思います。

この機能の絶対的に最も一般的な使用法は、変更されていないWebアセット、images / js / cssを提供することだと思います。

しかし、私の言葉を信じないでください。ブラッドのfileembedのインポーターのいくつかを見てみましょう。

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

#fileembed pattern .*\.png



md5-f8b48fccd03599094034bf2b507e9e67



#fileembed pattern .*\.js$

等々..

事例データの場合：これが実装されていれば、すぐに2つの場所で使用し、どちらも静的テキストファイルへの変更されていないアクセスを提供することになります。 現在、 //go:generateステップを使用して、ファイルを定数（16進形式）文字列に変換しています。

指令ではなく、新しいパッケージに投票します。 把握しやすく、取り扱い/管理がはるかに簡単で、文書化と拡張がはるかに簡単です。 たとえば、「go：generate」などのGoディレクティブのドキュメントを簡単に見つけることができますか？ 「fmt」パッケージのドキュメントはどうですか？ 私がこれでどこに行くのか分かりますか？

したがって、代わりに、Goは、デフォルトでgo buildで実行される独自の「公式」埋め込みツールを持つことができます

@andreynering他のパッケージマネージャーや言語ツールで許可されていることは知っていますが、ビルド時に任意のコード/コマンドを実行することはセキュリティの脆弱性です（明らかな理由であると思います）。

この機能について考えるとき、さらに2つのことが頭に浮かびます。

• 埋め込みファイルはビルドキャッシュでどのように自動的に機能しますか？
• 再現性のあるビルドを妨げますか？ データが何らかの方法で変更された場合（たとえば、データを圧縮する場合）、再現性を考慮に入れる必要があります。

最初のコメントでリンクされているstuffbinは、主に自己ホスト型Webアプリケーションが静的（HTML、JS ...）アセットを埋め込むことができるように構築されました。 これは一般的な使用例のようです。

コンパイル/圧縮の議論を除けば、もう1つの問題点は、stdlibにファイルシステムの抽象化がないことです。理由は次のとおりです。

• 開発者のマシンでは、多数のgo runとビルドが、アセットの埋め込み（オプションで圧縮中）のオーバーヘッドによって負担される必要はありません。 ファイルシステムの抽象化により、開発中にローカルファイルシステムに簡単にフェイルオーバーできます。

• アセットは、開発中にアクティブに変更される可能性があります。たとえば、Webアプリケーションの完全なJavascriptフロントエンドです。 埋め込みアセットの代わりに埋め込みとローカルファイルシステムをシームレスに切り替える機能により、アセットが変更されたという理由だけでGoバイナリのコンパイルと再実行を回避できます。

編集：結論として、埋め込みパッケージがhttp.FileSystemよりも優れたファイルシステムのようなインターフェイスを公開できれば、これらの懸念は解決されます。

埋め込みとローカルファイルシステムをシームレスに切り替える機能

確かに、これはアプリケーションレベルで実装でき、この提案の範囲を超えていますね。

確かに、これはアプリケーションレベルで実装でき、この提案の範囲を超えていますね。

申し訳ありませんが、気付いたばかりですが、私が言った方法はあいまいです。 私はembedパッケージ内にファイルシステムの実装を提案していませんでしたが、 http.FileSystemよりも優れたインターフェイスだけを提案していました。 これにより、アプリケーションはあらゆる種類の抽象化を実装できるようになります。

編集：タイプミス。

@knadh go run使用するだけでも機能するはずであることに完全に同意します。これは、Packrがこれを処理する方法が非常に優れています。 ファイルがアプリに埋め込まれていない場合は、ファイルがどこにあるかを認識し、基本的に「開発モード」であると想定して、ディスクからファイルをロードします。

Packrの作者は、Goモジュールに重点を置いた新しいツールPkgerもリリースしました。 そこにあるファイルはすべて、GoModuleルートに関連しています。 私はそのアイデアが本当に好きですが、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の使用がデータを非圧縮にする必要があることを示している場合、 const入力でFileReaderAt()を使用すると、すべてのファイルを非圧縮で保存する必要があります。

それが良いのか悪いのかわかりません。 魔法のヒューリスティックは、最初は赤面しているように見えるほど有用ではないと思います。

特別なディレクトリ名（ static/ ）の代わりにコメントプラグマ（ //go:embed ）を支持する1つの引数：コメントを使用すると、パッケージ（または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/")

'release'モードでは、実行可能ファイルのパスに代替の場所をロックするのがおそらく最善ですが、devモードではこれを緩和します（go_pathなどのフォルダーのみを許可します）

デフォルトでは、パッケージはinternal：//またはその他のキーワードを「マウント」しますが、必要に応じてユーザーが名前を変更できるようにします。例：ReMount（ "internal"、 "myCustomName"）など。

別のこと...別の場所で最終変更/変更時刻を確認し、アプリケーションの外部にそのようなファイルがある場合は内部ファイルを自動的にオーバーライドすることは理にかなっています（これを可能にするフラグがあり、ビルド前にプログラマーが構成できます）
これは、新しいビルドが作成されて配布されるのを待ちたくないアプリケーションの超高速パッチに必要な場合があります。フォルダを作成してそこにファイルをコピーするだけで、バイナリが新しいものに切り替わります。ファイル。

Windowsでは、リソースを使用することは可能でしょうか、または意味がありますか（リソース内のバイナリデータブロブのように）
少し関係ありませんが、このパッケージは、実行可能ファイル、マニフェストデータ、またはその他のリソース内のアイコンのバンドルも処理できる可能性がありますか？ 私はそれがWindowsだけだと気づきます...
ビルダーは、代替フォルダー内のファイルの最終変更日/変更日をログに記録し、ファイルが変更されてそのBLOBをどこかにキャッシュした場合にのみ、「データのBLOBの作成」をトリガーできると思います。
たぶん、「キャッシュ」ファイルを作成するだけで、ユーザーはこれらのバンドルファイルの圧縮を有効にすることを選択します（最終的にそれらを圧縮することが決定された場合）...圧縮が選択された場合、変更された特定のファイルのみをビルド時に再圧縮する必要があります、他のファイルはキャッシュからバイナリにコピーされるだけです。

私が見る問題の1つは、パッケージでカスタム名が許可されている場合、「udp、file、ftp、http、https、およびその他のさまざまな一般的なキーワード」を許可しないなど、何らかのブラックリストが必要になることです。

バイト配列/文字列または圧縮として保存することに関しては...どんな決定がなされても、将来簡単に更新する余地を残す必要があります...例：圧縮なしで開始し、オフセットとファイルサイズのリストを持っているだけでファイル名ですが、将来的に簡単に圧縮を追加できるようにします（exメソッドzlib、lzma、圧縮サイズ、チャンクを解凍するのに十分なメモリを割り当てる必要がある場合は非圧縮サイズなど）。

実行可能ファイルをUPXまたは同等のものと一緒にパックできれば、個人的には嬉しいです。バイナリがメモリにアンパックされ、すべてが機能すると思います。

間接的に関連するいくつかの考え：

• Go構文を使用するためのpackage embedアプローチが好きです
• 圧縮やその他の操作の必要性はバイナリサイズではなく、誰かが再生成を忘れる「同期していない」状態がないように、最も差分に適した形式のコンテンツだけをリポジトリに保存したいということだと思います。 「ソース」を変更するときに圧縮フォームをコミットし、パッケージを「取得可能」のままにします。 これらの点に対処せずに、私たちは標準化の問題を解決しているだけです。これは許容できるかもしれませんが、理想的ではないようです。
• 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())
    ...
}

2番目の形式では、コンパイル時にEncodeステップを実行する必要があるため、ツールチェーンが使用するコーデックを静的に理解する必要があるという複雑さがあります。 したがって、コンパイル時に簡単に決定できないコーデック値は許可しない必要があります。

これらの2つのオプションを考えると、私は魔法のコメントとコーデックを選択すると思います。 これにより、ここで述べたすべての目標に対応する、より強力な機能が実現します。 さらに、ここでは魔法のコメントは受け入れられないと思います。 現在、この目的のために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コメントを解析し、それらのパターンをグロブし、それらのファイルをハッシュし、 &websiteを使用してランタイムに登録します。

ランタイムには、各ファイルアドレスの内容と、ファイル実行可能ファイルのどこにあるか（または、ELF / etcセクション名が何であるか）のマップが効果的に含まれます。 そして、圧縮を行うことになった場合、ランダムアクセスをサポートするかどうかにかかわらず、おそらく。

@gdamore 、

ここでもう1つの問題があります。DTraceソースコード（埋め込み）を使用する別のプロジェクトがあります。 これは、nとrnの違いに敏感です。
..。
さまざまな変更でうまくいかない場合、それはこの新しい機能を使用することに反対する議論です。

また、実行時に変更して、goinstallを実行しているWindowsユーザーから埋め込まれたキャリッジリターンを削除することもできます。 私はそのio.Readerフィルターを数回書いた。

しかし、私が持っていた認識のために圧縮がないという出くわしました：最も圧縮可能なコンテンツ（HTML、JS、CSSなど）は、まだランダムアクセスが必要なコンテンツです（たとえば、範囲要求をサポートするhttp.FileServerを介して提供されます）

圧縮とランダムアクセスは完全に相互に排他的ではありません。 たとえば、ここでいくつかの議論を参照してください： https ：

圧縮とランダムアクセスは完全に相互に排他的ではありません

ええ、適切な位置に到達するためにオーバーヘッドを伴う粗粒度のシークが必要な場合。 私はこのスペースでCRFSのstargzフォーマットを使っていくつかの作業を

オーバーヘッドが十分に大きいので、人々のために自動的にそれをしたくないのではないかと心配しています。

けっこうだ。 重要な問題は、変更が必要な場合、または実験でオーバーヘッドが許容できることが示された場合に、後でこれについて安価に考えを変えることができる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が指定された名前で埋め込まれていることです。 この例では、 go runを含むふりパッケージを使用して、コマンドOSを独立させる方法を示しています。これは、Goがコンパイルするすべての場所でcat使用できるとは限らないためです。

これにより、変換の「エンコード」ステップが処理され、「デコード」ステップのタスクはユーザーに任せることができます。 ランタイム/埋め込みパッケージは、エンコーディングに関係なく、ユーザーがツールチェーンに埋め込むように要求したバイトを提供するだけです。 ユーザーはデコードプロセスがどうあるべきかを知っているので、これは問題ありません。

これの大きな欠点の1つは、埋め込まれたバイトがzipか何かである以外に、この方法で複数のファイルのグロブを埋め込む良い方法が見当たらないことです。 グロブはzipコマンドで使用できるので、実際にはそれで十分かもしれません。グロブを本当に気にするのは定義側です。 しかし、この提案から2つの機能を使用することもできます。1つは単純な埋め込みを実行する機能で、もう1つはジェネレーター埋め込みを実行する機能です。

私に発生した可能性のある欠点の1つは、埋め込みがgo buildによって処理され、 go generateように追加のツールチェーン呼び出しを必要としないことを前提として、ビルドに自由形式のステップが追加されることです。 でも大丈夫だと思います。 おそらく、ツールは、コストのかかる操作の繰り返しを回避するために独自のキャッシュを管理することが期待できます。あるいは、ツールチェーンと通信してGoのキャッシュを使用することもできます。 それは解決できる問題のように聞こえ、 go buildが私たちのためにより多くのことをするという全体的なテーマ（モジュールのフェッチなど）に適合します。

このプロジェクトの目標の1つは、Goビルドに外部ツールやgo：generate行が不要であることを確認することですか？

そうでない場合は、物事をシンプルに保ち、バイトスライスまたは文字列のみをサポートする価値があるようです。ユーザーが多数のノブで圧縮したい場合は、makeファイル（または同様のもの）で圧縮したり、とにかくビルドする前に行を生成したりすることができます。したがって、この提案の結果がどうなるかに関係なく、それらを追加する価値はないようです。

Makeなどを必要としないことが目標である場合は、圧縮を使用するのが理にかなっていると思いますが、個人的には、Makeや生成などを使用して圧縮を行い、埋め込みを単純にして、いくつかのバイトを埋め込むだけです。 。

@SamWhited 、

このプロジェクトの目標の1つは、Goビルドに外部ツールやgo：generate行が不要であることを確認することですか？

はい。

go：generate、Makefiles、またはその他のツールを使用したい場合、今日では数十の選択肢があります。

デフォルトで機能する、ポータブルで安全で正しいものが必要です。 （明確にするために：安全とは、go：generateがデフォルトで実行されないのと同じ理由で、「goinstall」時に任意のコードを実行できないことを意味します）

@ stephens2424

埋め込みインタラクションがオプションで「コーデック」を提供できる場合は、特定の圧縮/変換をアクティブにサポートする必要があるツールチェーンの必要性を回避できると思います。

go build中に任意のコードが実行されることはありません。

goビルド中に任意のコードが実行されることはありません。

ええ、私は今それを見ます。 「ソース」ファイルのみをリポジトリにコミットし、「処理済み」ファイルを埋め込み、パッケージを「取得可能」にし、 go buildシンプルかつ安全に保つ方法はないと思います。 私はまだここで標準化を推進していますが、私は自分のケーキを持ってそれも食べたいと思っていたと思います。 試してみる価値！ 問題を見つけてくれてありがとう！

@flimzy

これにより、リフレクションを介して他の方法を使用できなくなります。

私が述べたことにはメソッドはなく、関数だけです。 それらは実行時に発見できず、ソースで名前で言及せずにそれらを参照する方法はありません。 また、異なる関数によって返されるインターフェイス値は同じタイプである必要はないことに注意してください。実際、そのインターフェイスを実装するために必要なメソッドを備えた非エクスポートタイプか、 *strings.Readerインスタンスのいずれかであると予想されます

ただし、間違いなく、このアイデアには、埋め込みパッケージのエクスポートされた関数を値として渡すという問題があります。 それでも問題にはならない可能性がありますが、署名にはエクスポートされていない型が含まれているため（以下を参照）、変数、引数、またはそれらの型の戻り値を宣言することはできません。 理論的には、それらをreflect.ValueOf自体に渡すことができます。 それで実際にそれらを呼び出すことができるかどうかさえわかりません（エクスポートされていないパラメータタイプの値を作成する必要があります。reflectで許可されている場合はDunno）。

ただし、次のようになります。 embed最上位関数が値として使用され、すべての埋め込みファイルに制限が生じる場合に備えて、単純に悲観的になる可能性があります（最も単純です）。 つまり、embed-packageを使用して非常に奇妙で役に立たないことを行うことにした場合、いくつかの最適化が失われます（とにかく、必ずしも約束するわけではありません）。 公平なようです。

実際、その影響はそれよりも広いと思います。 FileReaderAtの使用がデータを非圧縮にする必要があることを示している場合、非定数入力でFileReaderAt（）を使用すると、すべてのファイルを非圧縮で保存する必要があります。

埋め込みを行うにはファイル名を静的に知る必要があるため、非定数入力を許可することは意味がありません。 ただし、ファイル名パラメーターのタイプとしてstringを使用するのは不正確でした。これらは、実際にはエクスポートされていないtype filename stringあり、関数の引数としてのみ使用されるべきでした。 そうすれば、型指定されていない文字列定数以外のものを渡すことは不可能です。

@Merovius

非定数入力を許可することは意味がありません

私たちはさまざまなことについて話していると思います。 アクセサ関数への入力（つまり、 FileReaderAt() ）を意味します。ここでは、非定数入力が理にかなっていることに同意すると思います。

そして、私のポイントは次のとおりです。100個のファイルを埋め込んだものの、 FileReaderAt(filename)呼び出しがあり、 filenameは一定ではありません。 この方法でどの埋め込みファイルにアクセスするか（実際に存在する場合）を知る方法はないため、すべてを非圧縮で保存する必要があります。

@flimzy私たちは同じことについて話していました、私は非constファイル名が意味をなさないと真剣に考えていませんでした:)それを考えると、それは間違っていて見落としでした。 申し訳ありません。 ディレクトリ全体をグロブまたはインクルードしてからそれらを反復処理する機能は、実際には非常に重要です。 それでも、これは解決できると思う-コレクションごとの意思決定をすることにより、例えば（DIR /グロブ）とのみ定数名によってそれらを選択することができます-しかし、私は言ったように：それは実際にAPI Iが原因のGOツールのためのスーパー適切に検討するではありませんそれはなんて魔法なのでしょう。 したがって、このように雑草に入ると、おそらく、概念に値するよりも多くのスペースが議論に与えられます:)

以前のメッセージでは見られず、ファイルをGoバイナリに埋め込むことを検討した別のケースは、通常のgoビルド/インストールを使用してC共有ライブラリのラッパーパッケージを適切に配布できないことでした（共有ライブラリはソース）。

私は結局それをしませんでした、しかしそれは私がこの場合のためにそれを再考することを間違いなくさせます。 Cライブラリには確かに多くの依存関係があり、共有ライブラリとして配布する方が簡単です。 この共有ライブラリは、Goバインディングによって埋め込むことができます。

わお！！！

@ジュリオ-ゲラ
それらをディスクに抽出してから、dlopenとdlsymを使用してC関数を呼び出す必要があると確信しています。

編集：あなたの投稿を少し誤解しました、あなたが配布用のバイナリを作成することについて話していることに気づきました

http静的アセットの外部で、メモリ内へのポインタに必要な埋め込みBLOBの場合、すでに処理中の埋め込みメモリへのポインタを返す関数があると便利です。 そうしないと、新しいメモリを割り当てて、io.Readerからコピーを作成する必要があります。 それは2倍のメモリを消費します。

@glycerine 、繰り返しますが、それはstringです。 stringはポインタと長さです。

コンパイル時に実行するコードにマークを付け、実行時に結果を提供する方法があると便利ではないでしょうか。 そうすれば、任意のファイルを読み取って、コンパイル時に必要に応じて圧縮し、実行時にアクセスすることができます。 これは、ファイルコンテンツのプリロードで機能するため、一部の計算では機能します。

スレッドで前に述べたように、 @ burkaは、 go buildは任意のコードを実行しません。

@burka 、それは明らかに範囲外です。 その決定（コンパイル時にコードが実行されない）はかなり前に行われたものであり、これはそのポリシーを変更するためのバグではありません。

この提案の副作用は、goプロキシが保存するファイルをgoファイルのみに最適化できないことです。 プロキシは、GoコードにGo以外のファイルが埋め込まれているかどうかがわからないため、リポジトリ全体を保存する必要があります。

プロキシがすでにこれを最適化しているかどうかはわかりませんが、いつかは実現可能になるかもしれません。

@leighmccullochでも、今日もそうは思わない。 Goパッケージ内のGo以外のファイルは、 go testで必要になる可能性があるため、モジュールアーカイブに含める必要があります。 別の例として、cgo用のCファイルがある場合もあります。

これはエキサイティングな方向性であり、ユースケースには間違いなく必要です。

とはいえ、要件が異なるさまざまなユースケースがあるように感じますが、それを実行する必要があると考える_方法_についてコメントしているほとんどの人は、暗黙的に独自のユースケースを想定していますが、明示的に定義していません。

ファイル埋め込みソリューションのさまざまなユースケースと、各ユースケースが提示するできれば、役立つかもしれません—少なくとも私にとっては本当に役に立ちます—。

たとえば、私たちの主なユースケースは、HTML + CSS + JS + JPG + etcを埋め込んで、goアプリの実行時に、 http.FileServerで提供できるようにそれらのファイルをディレクトリに書き込むことができるようにすることです。 。 Goからファイルにアクセスする必要がないため、リーダーとライターについて私が読んだコメントのほとんどが私にとって異質なユースケースであることを考えると、 go-bindataそれらをディスクにコピーさせるだけです_（ただし検討すべきことにまだ気付いていない、より優れた手法を活用する方法があるかもしれません。）_

ただし、課題は次のとおりです。通常、デバッガーでGoLandを使用し、継続的な変更を行うWebアプリで作業します。 したがって、開発中にソースディレクトリから直接ファイルをロードするにはhttp.FileServerが必要です。 ただし、アプリの実行時に、 http.FileServerは、埋め込みソリューションによってファイルが書き込まれたディレクトリからこれらのファイルを読み取る必要があります。 つまり、コンパイルするときに、go-bindataを実行してファイルを更新してから、Gitにチェックインする必要があります。 そして、それはすべて一般的にgo-bindataで実行可能ですが、確かに考えられていません。

ただし、コンパイルされた実行可能ファイルを実際に実行する必要がある場合もあります。そのため、実行中のプログラムにデバッガーをアタッチしても、埋め込みファイルがgo-bindataによって書き込まれるディレクトリからではなく、ソースディレクトリからファイルをロードできます。

これらが私たちのユースケースと課題です。 たぶん、他の人が他のユースケースと関連する一連の課題を明示的に定義できるので、これらの議論はさまざまな問題空間に明示的に対処でき、および/またはこの取り組みが特定の問題空間の特定のニーズに対処しないことを明示的に示すことができますか？

よろしくお願いします。

ユースケースとして言及されていないので、template.ParseFilesを介してアクセスするテンプレートのディレクトリにもこれが役立ちます。

最もクリーンなアプローチは、 go.mod介してオプトインする方法だと思います。 これにより、下位互換性が確保され（既存のプロジェクトではオプトインして使用する必要があるため）、ツール（goプロキシなど）で必要なファイルを判別できます。 go mod initコマンドを更新して、新しいプロジェクトのデフォルトバージョンを含め、将来使いやすくすることができます。

ディレクトリを標準名にする（オプトインが必要な場合は、よりクリーンでシンプルな名前にすることができます）、またはディレクトリの名前をgo.mod自体で定義し、ユーザーが次のことを行えるようにするための引数を確認できます。名前を選択します（ただし、デフォルトはgo mod init提供されます）。

私の考えでは、このようなソリューションは、使いやすさと「魔法」の減少のバランスを実現します。

@jayconrodは書いた：

特別なディレクトリ名（static /）の代わりにコメントプラグマ（// go：embed）を支持する1つの引数：コメントを使用すると、パッケージ（またはxtestアーカイブ）のテストアーカイブにファイルを埋め込むことができますが、ライブラリは埋め込むことができませんテスト中。

これは本当に素晴らしい観察です。 我々は特別なディレクトリ名を指定して行きたいと思ったならば、我々はおなじみのメカニズムを使用することができますが： staticすべてのビルドのために、 static_testテストビルドのために、 static_amd64 AMD64用のビルド、およびすぐ。 ただし、任意のビルドタグサポートを提供する明確な方法はわかりません。

静的ディレクトリにマニフェストファイルが存在する可能性があります（空のマニフェストが指定された場合のデフォルトはマニフェスト以外のすべてを含みます）。これにはグロブが含まれ、ビルドタグや後で圧縮などを指定できます。

1つの利点は、goリストがマニフェストを含むdirにヒットした場合、そのツリーをスキップできることです。

欠点の1つは、非常にhtaccesが発生する可能性があり、感謝しないことです。

ファイルをパッケージにバンドルするための単純なゼロノブメカニズムは、パッケージディレクトリ内の特別なディレクトリ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つ下のディレクトリレベルまたはおそらく1つ下のディレクトリレベルのファイルへのインポートを制限すれば、セキュリティの問題と再現性は問題にならないはずです。これもスレッドですでに説明されています。 絶対埋め込みパスは、そのdirectoyレベルに関連して解決されます。

コンパイルプロセス中にファイルにアクセスできないと、コンパイラエラーが発生します。

バイナリの背後にzipアーカイブを作成することも可能であるため、効果的に自己解凍型バイナリになることができます。 たぶん、これはいくつかのユースケースで役立ちますか？ ここで実験としてこれを行いました： https ：

Goにはすでに「testdata」があります。 ユニットテストでは、通常のIOを使用して、やりたいことをすべて実行します。 テストスコープは、コンテンツが出荷されていないことを意味します。 知っておくべきことはこれだけです。フリル、魔法、圧縮されたコンテナロジック、設定可能なインダイレクション、META-INFはありません。 美しく、シンプルで、エレガント。 バンドルされたランタイムスコープの依存関係用の「データ」フォルダーがないのはなぜですか？

Github eaの既存のGoプロジェクトを簡単にスキャンして、すでに「データ」フォルダーを使用しているため、調整が必要なプロジェクトをいくつか思いつくことができます。

私にははっきりしないもう一つのこと。 staticディレクトリの議論については、 static _source_ディレクトリについて議論しているのか、ファイルが_atで利用可能になるstaticディレクトリについて議論しているのかは100％明確ではありません。 runtime_ ？

また、この区別は、開発プロセスと開発中のコードのデバッグに関連しているため、特に重要です。

@mikeschinkel元の投稿から、ビルド時に埋め込みが行われることはかなり明らかです。

go install / go buildに埋め込みを自動的に行わせる

元の投稿と上記のコメントの一部では、実行時にファイルをロードするための「開発」モードについても説明しています。

@mvdan回答ありがとうございます。 つまり、提案された/static/ディレクトリは、アプリリポジトリ、パッケージリポジトリ、またはその両方のルートに相対的であると考えていますか？

そして、ランタイムファイルのその場所は、開発者がそれらを配置したい場所に完全に依存しますか？

それがすべて真実であり、論理的であると思われる場合は、デバッグ情報を使用してコンパイルされたプログラムが、オプションでソースの場所からファイルをロードして、多くの追加の（標準化されていない）ロジックやコードなしでデバッグを容易にすることができれば便利です。

上記の数人がモジュールプロキシについて言及しました。 これは、この機能を適切に設計するための優れたリトマス試験だと思います。

今日では、ユーザーコードを実行せずに、ビルドで使用されていないファイルを削除する実行可能なモジュールプロキシを実装することが可能であるように思われます。 上記の設計の一部は、モジュールプロキシがユーザーコードを実行して、どの静的ファイルも含める必要があるかを判断する必要があることを意味します。

人々はまた、オプトインとしてgo.modについて言及しました。

アイデア：go.modファイルの仕様？ 他のツールが簡単に解析できるようにします。

module github.com/foo/bar

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

これにより、コンパイル時にファイルデータを使用してパッケージが作成されます。 ここでは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. さらに、埋め込みファイルのコレクションは、1回限りの構文を使用してGoプロジェクトにアドホックに追加するのではなく、パッケージを含めることができれば、より価値があり、再利用できるように感じます。 ここでの考え方は、埋め込みがパッケージとして実装されている場合、人々はGithubを介してそれらを開発および共有でき、他の人はプロジェクトでそれらを使用できるということです。 以下を含むGitHub上のコミュニティが管理する無料のパッケージを想像してみてください。

   NS。 各ファイルにその国のすべての郵便番号が含まれている国のファイル、
   NS。 ブラウザを識別するためのすべての既知のユーザーエージェント文字列を含むファイル、
   NS。 世界各国の旗の画像、
   NS。 Goプログラムで一般的に発生するエラーを説明する詳細なヘルプ情報、
   e。 等々...

3. goembed://などの新しいURLスキーム（または既存のスキーム）を使用して、パッケージからファイルを開いたり読み取ったりできるため、新しいファイルを作成する代わりに、_（すべて？）_の既存のファイル操作APIを活用できます。現在のパッケージに含まれている埋め込みに関連する次のようなもの：

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

上記の概念では、_ "魔法" _のように感じるものはありません。 すべてが目的のために意図されたように感じるメカニズムによってエレガントに処理されます。 必要な拡張はほとんどありません。 go.mod 1つの新しい動詞と、Goによって内部的に認識される1つの新しいURLスキーム。 それ以外はすべて、Goからそのまま提供されます。

私が今していること

私は今これにcode.soquee.net/pkgzipを使用しています（グローバルな状態とインポートの副作用を回避するためにAPIを変更するのはstatikフォークです）。 私の通常のワークフロー（少なくともWebアプリでは）は、ZIPファイルにバンドルされたアセットを埋め込み、 golang.org/x/tools/godoc/vfs/zipfsとgolang.org/x/tools/godoc/vfs/httpfsを使用してそれらを提供することです。

go：embedアプローチ

私がgo:embedアプローチを採用することをおそらく妨げる2つのことがあります：

1. 生成されたコードはドキュメントに表示されません
2. アセットはコードベース全体に散在している可能性があります（これは外部ツールとgo:generateを使用する場合にも当てはまります。そのため、通常、ビルドする前にmakefileを使用してさまざまなアセットのセットを生成することを好みます。それらすべてをmakefileで見ることができます）

アセットを（モジュール全体ではなく）パッケージの一部にすることは、ビルドタグ、パッケージのテストなどのすべての複雑さを意味するという一部の機能である可能性があるため、上記に含めない問題もあります。 。それらに適用する場合、それらがそのパッケージに対してパブリックであるかプライベートであるかを指定する方法などが必要です。これは、ビルドが非常に複雑になるようです。

私が気に入っているのは、アセットのインポートを簡単にするライブラリを作成できることです。 例えば。 フォントを埋め込むだけの単一のGoファイルを含むライブラリ、またはいくつかのアイコンを公開して、他のGoパッケージと同じようにインポートすることができます。 将来的には、インポートするだけでアイコンフォントを取得できるようになります。

import "forkaweso.me/forkawesome/v2"

埋め込みパッケージアプローチ

これをすべて明示的で通常のGoコードにするというアイデアは好きですが、これが標準ライブラリの外部では実装できない別の魔法のパッケージになるというアイデアは嫌いです。

そのようなパッケージは言語仕様の一部として定義されますか？ そうでなければ、Goコードが異なる実装間で壊れてしまう別の場所であり、これもまた貧弱な感じがします。 この破損を防ぐために、外部ツールを使い続けると思います。

また、他の人が言及しているように、これがビルド時に行われているという事実は、このパッケージが引数として文字列リテラルまたは定数のみを取ることができることを意味します。 現在、型システムでこれを表現する方法はなく、混乱のポイントになると思います。 これは定数関数のようなものを導入することで解決できますが、今は主要な言語の変更について話しているので、初心者ではありません。 そうでなければ、これを修正する良い方法がわかりません。

ハイブリッド

私はハイブリッドアプローチのアイデアが好きです。 コメントを再利用する代わりに（最終的にはあちこちに散らばり、個人的なメモでは、ただグロスに感じます）、すべてのアセットを1つの場所に配置し、おそらくgo.modファイルを他のアセットと同じように表示したいと思います。言った：

module forkaweso.me/forkawesome/v2

go 1.15

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

つまり、アセットは、個別のモジュールを作成せずに、任意のビルドタグ、または任意のパッケージ（_testingパッケージなど）に含めたり除外したりすることはできません。 この複雑さの軽減が望ましいと思います（インポートしようとしているライブラリにビルドタグが隠されておらず、ライブラリをインポートするとアセットが埋め込まれているはずなので、適切なアセットがない理由がわかりません） 、しかしYMMV。 これが望ましい場合は、コードを生成せず、代わりに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とアセットの選択方法には、いくつかの作業が必要になる場合があります。

さらに別のアイデア： go.modに新しい種類の動詞embedを追加する代わりに、新しい種類のパッケージであるデータパッケージを導入して、go.modでインポートして使用することができます。通常の方法。 これがストローマンのスケッチです。

パッケージに.goファイルstatic.goだけ含まれていて、そのファイルにコメントとパッケージ句のみが含まれている場合、パッケージはデータパッケージです。 インポートされると、cmd / goは、結果のバイナリに埋め込まれているファイルへのアクセスを提供するエクスポートされた関数をパッケージに入力します。

それが実際のパッケージである場合、それはinternalルールが適用され、APIに追加せずにアクセス制御を持つことができることを意味します。

.go以外のすべてのファイルとサブフォルダー（実際のコードルールがない場合）をディレクトリに自動的に含めるのはどうですか？

パッケージに.goファイルstatic.goだけ含まれていて、そのファイルにコメントとパッケージ句のみが含まれている場合、パッケージはデータパッケージです。

このチェックは、ビルドタグを適用する前に実行されますか？ もしそうなら、それは避けたいかもしれないさらに別の特別な場合のようです。 そうでない場合、パッケージが一部のビルドタグの標準のGoパッケージと見なされ、他のビルドタグのデータパッケージと見なされる可能性があります。 それは奇妙に思えますが、多分それは望ましいですか？

@flimzy
これにより、1つのタグで埋め込みファイルを使用し、生成されたパッケージと同じ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のサポートが必要になります。

実際には、言語を変更せずにこれを行う方法があります。static.goには、cmd / goが入力する内容と完全に一致するボディレス関数が含まれている必要があります。

static.goに、cmd / goが入力する内容と完全に一致するボディレス関数を含める必要があります。

すべての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チームが特別なコメントや魔法のパッケージよりもgo.modを採用していると仮定すると、 go.modはインポートするファイルのリストを指定する正しい場所です。 それは、Goチームがgo.pkgファイルを追加することを決定しない限りです。

さらに、Goチームが埋め込みファイルを指定する場所としてgo.modを受け入れる場合、ファイルを埋め込みたい人は、 embed説明とパッケージをgo.mod提供する必要があります。 go.modファイルが存在するディレクトリで表されるものは、埋め込みファイルを含むパッケージになります。

しかし、それが開発者の望みではない場合は、別のgo.modファイルを作成し、埋め込みファイルを含めるパッケージのディレクトリに配置する必要があります。

これらの制約が機能しないと想定する正当なシナリオはありますか？

@mikeschinkel 、モジュールは_related_パッケージのコレクションです。 ただし、モジュール内の他のパッケージの推移的な依存関係（およびデータ！）を取得せずに、モジュールから1つのパッケージを使用することは可能です（そして合理的です！）。

データファイルは通常、モジュールごとではなくパッケージごとの依存関係であるため、これらの依存関係を見つける方法に関する情報は、個別のモジュールレベルのメタデータとして保存するのではなく、パッケージと同じ場所に配置する必要があります。

@bcmills

メッセージ内の「データファイル」を「モジュール」に置き換えることができるようですが、それでも当てはまります。
独自の特定のパッケージの依存関係として特定のモジュールを持つことは非常に一般的です。
それでも、それらすべてをgo.mod内に配置します。

@urandom 、 go.modファイルに示されているモジュール内のすべてのパッケージが最終的なバイナリにリンクされているわけではありません。 （ go.modファイルに依存関係を置くことは、その依存関係をプログラムにリンクすることとは_等しくありません_。）

メタポイント

これが多くの人々が気にかけていることであることは明らかであり、上部のブラッドの元のコメントは、最初のスケッチ/開始点/行動の呼びかけよりも完成した提案ではありませんでした。 この時点で、この特定の議論を終わらせ、ブラッドとおそらく他の数人が詳細な設計ドキュメントで共同作業を行い、その特定の（まだ書かれていない）ドキュメントの議論のために新しい問題を開始することは理にかなっていると思います。 それは、少し広大な会話になっていることに集中するのに役立つようです。

考え？

これを閉じることに同意するかどうかはわかりませんが、提案は可能です-設計ドキュメントが作成されるまで保留し、コメントを少しロックします。 （コメントが冗長であるかどうかを確認するにはコメントが多すぎるため、この時点ではほとんどすべてのコメントが冗長です...）

たぶん、デザインドキュメントがあるときは、これを閉じることができます。

または、これを閉じて＃3035を再度開き（コメントを凍結して）、少なくとも1つの未解決の問題がそれを追跡するようにします。

クロージングについて話し合った直後にこれを行って申し訳ありませんが、 @ bcmillsのコメントの直後で、明確にする前に、クローズの議論が

"_ただし、モジュール内の他のパッケージの推移的な依存関係（およびデータ！）を取得せずに、モジュールから1つのパッケージを使用することは可能です（そして合理的です！）。" _

はい、明らかにそれは_可能です。_しかし、他のベストプラクティスと同様に、データパッケージのベストプラクティスは、モジュール用の単一のパッケージを作成することであり、これにより懸念が解決されます。 それがルートにgo.modを意味し、データパッケージを含むサブディレクトリに別のgo.modを意味する場合は、そうです。

私はあなたがここで善の敵になることを完璧にしないことを主張していると思います。ここで善はgo.modとして識別され、埋め込みファイルを指定するのに最適な場所です。モジュールのコンポーネント。

申し訳ありませんが、パッケージはGoの基本的な概念であり、モジュールではありません。
モジュールは、1つのユニットとしてバージョン管理されるパッケージの単なるグループです。
モジュールは、個々のパッケージのセマンティクス以外に追加のセマンティクスを提供しません。
それは彼らの単純さの一部です。
ここで行うことはすべて、モジュールではなくパッケージに関連付ける必要があります。

これがどこに行っても、それがどのように行われたとしても、（使用されているパターンだけでなく）golistを使用して埋め込まれるすべてのアセットのリストを取得する方法があるはずです。

ブラッドと他の人が正式な設計ドキュメントを作成するまで保留にします。

特に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チームが新しいキーワードを導入したいかどうかはわかりません

私が覚えているアイデアは、静的データを含む「static」のような特別なディレクトリ名を設定し、注釈を必要とせずにAPIを介して自動的に利用できるようにすることでした。

特別なディレクトリ名としてstaticを使用するのは少し混乱するので、 assetsを使用したいと思います。
スレッドで見なかったもう1つのアイデアは、 assetsをパッケージとしてインポートできるようにすることです（例： import "example.com/internal/assets" 。 公開されたAPIにはまだデザインが必要ですが、少なくとも特別なコメントや新しいruntime/filesスタイルのパッケージよりもきれいに見えます。

スレッドで見なかったもう1つのアイデアは、アセットをパッケージとしてインポートできるようにすることです。

これはここで提案されました： https ：

複雑な点の1つは、タイプチェックを有効にするには、これを言語の変更にするか、cmd / goで入力する本文のない関数を提供する必要がある

これも同様のアイデアですが、 static.go設計では、任意のインポートパスをデータパッケージに変換できますが、 assetsディレクトリはtestdata 、 internalまたはvendor 「特別」であるという点でassetsが持つ可能性のある要件の1つは、Goパッケージを含まない（またはドキュメントのみを許可する）ことです。つまり、暗黙的な下位互換性のためです。

これは、ファイルを取得するためのruntime/files -thingyAPIと組み合わせることもできます。 つまり、生の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行のpackageヘッダー行の方が好きです。
  
  
• 「resource」または「io / resource」と呼ばれる新しいコアパッケージ。 現在のパッケージに埋め込まれているリソースを読み取るためのfunc Read(name string) (io.Reader, bool)関数が少なくとも1つあります。
  
  
  
  • __編集__コアパッケージがこのように機能するかどうかわからない。 生成されたパッケージプライベート関数である必要がある場合があります（例： func readresource(name string) (io.Reader, bool) ）
  
  
• サブディレクトリにリソースが必要な場合は、go.resファイルと少なくとも1つの.goファイルを追加して、サブディレクトリをパッケージにします。 goファイルは、サブディレクトリパッケージ内のリソースにアクセスするための独自のパブリックAPIをエクスポートします。 他のパッケージのリソースは（設計上）自動的にエクスポートされないため、goファイルとエクスポートされたAPIが必要です。 この方法でエクスポートする方法をカスタマイズすることもできます。
  
  
  
  • __Edit__または、ディレクトリ構造や圧縮が必要な場合は、tarリソースを使用します。 これにより、すでにコンパイルが必要な（そして、事前圧縮の恩恵を受ける可能性がある）webpackバンドルのようなものが可能になります。 それらをtarに一歩進めるのは簡単です。
  
  
• __編集__マニフェストが必要ですか？ go.resファイル自体をリソースとして含めるだけです。 listresources関数を作成する必要はありません。

非常にシンプルです。 1つの新しい機能。 1つの新しいファイル。 パスはありません。 圧縮なし。 新しい構文はありません。 魔法はありません。 拡張可能。 リーダーを介した読み取り専用アクセス（ただし、将来的には別のアクセスパターンを利用できるようになります）。 既存のパッケージを壊す可能性はほぼゼロです。 パッケージがgoのコアコンストラクトであることを維持します。

__Edit__ githubでlanguage:go filename:go.res extension:res検索した後、 go.resを使用するのはかなり安全なファイル名のようです。 goリポジトリには一致するものはなく、非goリポジトリにはわずかしか一致しません。

@ chris.ackermanmのアイデアが好きです。 しかし、私は組み合わせを好むでしょう：

ディレクトリ内の名前空間を指定するgo.resファイル。

これにより、

• 名前空間が異なる限り、複数のインクルード
• 以前にファイルを知らず、リストを生成する必要がある

後者は、更新やさまざまなオプションなどによってレイアウトが変更される可能性のあるwebpackなどの出力に取り組む必要があります。

圧縮に関して：バイナリサイズが爆発しないという点で、より多くの機能であり、使用するコードに対して透過的である必要があると思います。

後で、次のような書き換えを許可できます。

filename => stored-as.png

ちょうど私の2¢

@ sascha-andres非常にシンプルで、魔法がゼロのようです。このスレッドのトーンです。 私がコメントに対して行った編集を参照してください。

マッピングが好きではありません。 必要なし。 とにかく別のパッケージから独自の読み取り関数を公開することでそれが可能になり、新しいファイル構文、または1行あたりのファイルよりも複雑なものが必要になります。

やあ

この提案は素晴らしいです！

そして、私は、emebed資産への私のアプローチを持っています。 GNUbintools以外のツールを導入する必要はありません。 ちょっと汚いですが、今のところうまくいきます。 私はそれを共有して、それが役立つかどうかを確認したいと思います。

私のアプローチは、アセット（tar＆gzで圧縮）をobjcopyを使用してelf / pe32セクションに埋め込み、必要に応じてzipとともにパッケージdebug / elfおよびdebug / pe32を介して読み取ることです。 私が覚えておく必要があるのは、既存のセクションに触れないことだけです。 すべてのアセットは不変であり、コードはコンテンツを読み取り、メモリ内で処理します。

私は言語設計やコンパイラ設計にかなり不慣れです。 したがって、上記のアプローチを使用し、セクション名として.goassetsなどを使用します。 圧縮をオプションにします。

私のアプローチは、アセット（tar＆gzで圧縮）をobjcopyを使用してelf / pe32セクションに埋め込み、必要に応じてzipとともにパッケージdebug / elfおよびdebug / pe32を介して読み取ることです。 私が覚えておく必要があるのは、既存のセクションに触れないことだけです。 すべてのアセットは不変であり、コードはコンテンツを読み取り、メモリ内で処理します。

elf / pe32で動作するように聞こえますが、 mach-o / plan9どうですか？

もう1つの問題は、実行可能ファイルのファイルハンドルを開くことに依存していることです。実行可能ファイルが上書き/更新/削除された場合、これは異なるデータを返しますが、それが正当な問題なのか予期しない機能なのかはわかりません。

私は（ debug / machoを使用して）少しmach-o-x86-64を破損しているようです。 mach-o構造を理解していないだけで、 objcopy見たので長すぎる可能性があります）。

もう1つの問題は、実行可能ファイルのファイルハンドルを開くことに依存していることです。

プログラムローダーがリソースセクションをメモリにロードする（またはロードできる）と確信しているので、デバッグパッケージを使用する必要はありません。 ただし、データにアクセスするには、オブジェクトファイルをいじくり回す必要があります。

何が機能するか、たとえば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や、リンカーを使用しない他のターゲットのサポートができなくなります。

ここでの議論に基づいて、 @ bradfitzと私は、上記の2つのアプローチの中間に位置する設計を作成し、それぞれの最良と思われるものを採用しました。 ドラフトデザインのドキュメント、ビデオ、およびコードを投稿しました（以下のリンク）。 この問題に関するコメントの代わりに、この特定のドラフト設計に関するコメントについては、Reddit Q＆Aを使用してください-Redditは、GitHubよりも優れたディスカッションをスレッド化およびスケーリングします。 ありがとう！

ビデオ： https ：
デザイン： https ：
Q＆A： https ：
コード： https ：

@rsc私の意見では、go：embedの提案は、コンパイル時に_universal_サンドボックス化されたGoコードの実行を提供するよりも劣ります。これには、ファイルの読み取りと、実行時の消費に最適な_最適な形式_への読み取りデータの変換が含まれます。

@atomsymbolそれはこの問題の範囲外の何かのように聞こえます。

@atomsymbolそれはこの問題の範囲外の何かのように聞こえます。

私はそれを知っています。

提案を読み、コードをスキャンしましたが、これに対する答えが見つかりませんでした。この埋め込みスキームには、ディスク上のファイル（〜os.Stat）に関する情報が含まれていますか？ または、これらのタイムスタンプはビルド時間にリセットされますか？ いずれにせよ、これらはさまざまな場所で使用される有用なピース情報です。たとえば、これに基づいて変更されていないアセットに対して304を送信できます。

ありがとう！

編集：redditスレッドでそれを見つけました。

あなたがリストした再現性の懸念のために、すべての埋め込みファイルの変更時間はゼロ時間です。 （同じ理由で、モジュールは変更時間を記録しません。）

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

いずれにせよ、これらはさまざまな場所で使用される有用なピース情報です。たとえば、これに基づいて変更されていないアセットに対して304を送信できます。

ファイルデータハッシュに基づくETagヘッダーは、日付について何も知らなくてもその問題を解決します。 しかし、それが機能し、リソースを無駄にしないためには、http.HandlerFSまたは何かによって認識されている必要があり、ファイルごとに1回だけ実行する必要があります。

しかし、それが機能し、リソースを無駄にしないためには、http.HandlerFSまたは何かによって認識されている必要があり、ファイルごとに1回だけ実行する必要があります。

http.HandlerFSは、fs.FSが不変であることをどのようにして知るのでしょうか。 IsImmutable() boolオプションのインターフェイスが必要ですか？

http.HandlerFSは、fs.FSが不変であることをどのようにして知るのでしょうか。 IsImmutable() boolオプションのインターフェイスが必要ですか？

私はこれらのものの設計者ではないので、実装の詳細には触れたくありませんが、http.HandlerFSはそれがembed.FSタイプであるかどうかをチェックし、特別な場合としてそれに基づいて行動することができます。今すぐFSAPIを展開してください。 特に、ファイルシステムを不変として扱うようにHandlerFSに指示するオプション引数が存在する可能性もあります。 また、これがアプリケーションの起動時に行われ、すべてのctime / mtimeの値がゼロの場合、handlerFSはその情報を使用して、ファイルが変更されていないことを「知る」ことができますが、mtimeがないか、無効になっている可能性のあるファイルシステムもあります。そこにも問題があるかもしれません。

私はこの問題に関するコメントを見ていませんでした。

@atomsymbolおかえりなさい！ ここでまたコメントしてくださるのを見るのは素晴らしいことです。
私は原則として、サンドボックス化があれば多くのことが簡単になることに同意します。
一方で、多くのことが難しいかもしれません-ビルドは決して終わらないかもしれません。
いずれにせよ、今日はそのようなサンドボックスは絶対にありません。 :-)

@kokes詳細は
ただし、埋め込みを提供することを確認します。HTTPを介したファイルはデフォルトでETagを正しく取得します。

7月に投稿されたデザインドラフトを受け入れるために＃41191を提出しました。
この問題に取って代わって、この問題をクローズします。
ここで素晴らしい予備的な議論をありがとう。