Go: embed、cmd / go：埋め込みファイルのサポートを追加

embedをインポートせずに//go:embedディレクティブを使用すると、エラーになりますか？

@jimmyfrascheはい、第五に、最後のリストで弾丸https://go.googlesource.com/proposal/+/master/design/draft-embed.md#go_embed -directives。

@rscドラフトで見逃したかもしれませんが、コメントで言及した単一のファイルを埋め込む機能がわかりません。
また、1つのファイルをconst文字列として埋め込むこともできますか？
この素晴らしい提案をありがとう。

@pierrecドラフトドキュメントにはありません（「1つの追加」は上記のコメントのテキストです）。 const文字列は、プログラムの型をチェックするかどうかを決定する役割を果たしてしまう可能性があります。つまり、すべての型チェッカーは// go：embed'edconstsを理解する必要があります。 対照的に、varに固執する場合、タイプチェッカーは賢明ではなく、そのままにしておくことができます。 おそらくvarsに固執する必要があるようです。

varの代わりにconstが必要な特別な理由はありますか？ それらを使用することは、効率に関してはほぼ同じでなければなりません。 （const文字列への参照は、とにかく非表示のvarへの参照に相当する量までコンパイルされます。）

説明してくれてありがとう。 現時点では、静的アセットをconst文字列として埋め込む傾向があります。これが、私が尋ねた理由です。 私もvarsで大丈夫です！

興味深いので、次のようなことができます。

//go:embed version.txt
var Version string

また、version.txtを生成するための//go:generateコメントもある可能性があります。 それはmakefiles / ldflagsの大きなユースケースを切り取るでしょう。

ファイルが見つからない場合はエラーですか？ もしそうなら、技術的にどこでエラーが発生すると考えられますか？ リンク時？

go：embedがgo：generateの後に実行されることを確認して、バージョンを簡単に生成するなどのことができるようにすることはできますか？

go：embedがgo：generateの後に実行されることを確認して、バージョンを簡単に生成するなどのことができるようにすることはできますか？

私の理解では、 go:generateはgo generate発生し、 go:embedはgo buildます。

@carlmjohnsonはい、fooが存在しない場所で//go:embed fooと言うのは常にエラーです。
その行を含むソースファイルをコンパイルすると、エラーが発生します。
（そのソースファイルをコンパイルした後にfooを削除した場合でも、リンクステップに到達しません。goコマンドは、fooが削除されたため、パッケージを再構築する必要があることを認識します。）

この提案は、ETagについて何も言わずに完了することはできないと思います。
https://old.reddit.com/r/golang/comments/hv96ny/qa_goembed_draft_design/fzi0pok/

@ tv42 、はい、ETagを機能させます。 その形はよくわかりませんが、そうします。
（https://github.com/golang/go/issues/35950#issuecomment-685845173でも確認されています。）

mjibson/esc作業から気付いた2つの3つのこと：

• go:embedは、読み取り専用ファイルシステムとして埋め込むためにgoファイルを生成する必要がないため、 git porcelain反するgo:generate edファイルのタイムスタンプを変更する手間を省くことができます。 CIでのテスト-とてもいい
• 私が提案で見つけられなかったが必要なことの1つは、開発サイクル中に埋め込まれたファイルをライブリロードする機能です。 mjibson/escを使用すると、現在、ローカルファイルシステムを使用して（新しいファイルを取得しませんが）ビルドタグを使用して動作を変更するように指示することができます。 それが提案に何が当てはまるのだろうか？
• 更新私が覚えているもう1つのことは、たとえばアセットフォルダーをWebルートとしてエクスポートするには、 escがベースパス（の一部）を透過的に削除できる必要があるということです。

後付け：2番目のポイントは、組み込みファイルシステムまたはライブファイルシステムのいずれかを含めて使用するio/fs提案と併せて修正できると思いますか？ パスストリッピングをio/fsミドルウェアとして実装しますか？

@andig HTTPを介してファイルシステムを提供する場合、プレフィックスを削除することができます。 ライブリロードは、 io/fsラップするサードパーティライブラリによって実行できることに同意します。

もう1つ、私が正しく理解していれば、embedはファイルをパッケージに対してローカルで考慮し、 ..を禁止します。 私の現在の設計には/assetsと/server/があり、後者にはサーバーのコードが含まれており、今日は生成されたファイルをホストしています。 この提案では、サーバーからアセットにアクセスできないため、埋め込みをルートフォルダーに移動する必要があります。 これにより、通常のインポートとは異なるアクセシビリティの制約が課せられます。 これがセキュリティ上の理由で必要なのか、それともモジュールローカルの埋め込みを一般的に許可すべきなのか疑問に思いました。

もう1つ、私が正しく理解していれば、embedはファイルをパッケージに対してローカルで考慮し、 ..を禁止します。 私の現在の設計には/assetsと/server/があり、後者にはサーバーのコードが含まれており、今日は生成されたファイルをホストしています。 この提案では、サーバーからアセットにアクセスできないため、埋め込みをルートフォルダーに移動する必要があります。 これにより、通常のインポートとは異なるアクセシビリティの制約が課せられます。 これがセキュリティ上の理由で必要なのか、それともモジュールローカルの埋め込みを一般的に許可すべきなのか疑問に思いました。

アセットディレクトリにemed.goファイルを作成し、アセットを独自のパッケージとしてプログラムの他の部分で使用できるようにすることができます。

もう1つの明確な目標は、言語の変更を回避することです。 私たちにとって、静的アセットの埋め込みは、言語の問題ではなく、ツールの問題のように見えます。

同意しました。 私の意見では、このツールの変更をサポートするために言語に糖衣構文を追加することは、言語の変更です。 これは他の人には明らかだと思いますが、これは事実上コードとしてのコメントです。

魔法/砂糖は言語の単純さと読みやすさを損なうと強く感じています。 ファイルを埋め込む魔法のコメントを見逃しがちです。 これに対する応答は簡単に「大丈夫、それを使用しないでください」である可能性がありますが、この変更は、レビューアがこの機能を使用する他の人に注意を払う必要があり、変数宣言に関するコメントがビルドを壊したり失敗したりする可能性があることを覚えておく必要があることを意味しますコンパイル時。

これは混乱を招き、言語の使いやすさを損ない、明確なメリットのない不透明で大きなバイナリになると思います（最後の懸念に関しては、これはプレーンファイルの変更によるバイナリの再構築のアンチパターンにさえつながります）。 go modが--withNonGoCodeAssetsに許可されている場合、これにより、より複雑なビルドパイプラインを作成したくないほとんどの開発者のニーズが解決されると思います（エンドユーザーの配布は、ユーザーの問題）。

@tristanfisher 、言語とツールの変更についてのあなたの

膨満感については、私たちが見なければならないだろうと思いますが、プログラムが以前よりもはるかに大きくなるとは思いません。 人々は、任意のファイルをGoコードに変換し、それらをリポジトリにチェックインして、コンパイラーにビルドさせるツールを_すでに_実行しています。 この設計では、このプロセスからオーバーヘッドがいくらか削除されますが、新しいものは何も有効になりません。 簡単にできるようになった今、人々はそれを悪用するかもしれませんが、結局のところ、それがそれほど問題になるとは思いません。 （そして、依存関係がバイナリを膨らませるほど大きなものを埋め込んでいる場合は、いつでもその依存関係を使用しないことを選択できます。）

プレーンファイルの変更による再構築に関しては、依存関係は不変であるため、再構築をトリガーできるファイルは、独自のトップレベルモジュール内のファイルのみです。 再構築が必要以上に頻繁に行われていることに気付いた場合、唯一の説明は、（1）ファイルを埋め込んでいること、および（2）それらのファイルを変更していることです。 あなたはどちらかの原因について何かをすることを完全にコントロールするでしょう。 （依存関係が何を使用するかを選択したために、何らかの理由で追加の再構築やその他の費用が発生した場合は、まったく別のことです。ただし、ここではそうではありません。）

@rsc同意しないことは問題ないことに同意し、ご回答いただきありがとうございます。 私の感じでは、それがデフォルトで標準ツールに含まれていて、コメントが変数の暗黙的な初期化につながる可能性がある場合、それは言語の変更です。 その議論の外では、私の不快な気持ちは、（人間の）コードリーダーによって記憶される必要がある「魔法の」コメントとしてのより多くの指示の周りにあると思います。 これは、ビルド時に処理されるブロックコメントを介して新しい機能を追加するという不条理な結論につながる可能性があります。

そうは言っても、これがエコシステムに追加された場合、 embedインポートが必要になることに感謝します。これは、コードを監査するときの「ちょっと、頭を上げて」として何もないよりはましです。 go modが.go以外を許可することで、ほとんどのユースケースが解決され（ほとんどの人がWebサーバー用のglobファイルを使用することになると思います）、完全にツールを使用することになると思います。

リンカーについてのあなたのポイントは良いものだと思います。 また、これに対する私の気持ちを説明するのにも役立ちます。エンドユーザー（たとえば、単にパッケージをインポートする人ではない）が決定を下している場合、非コードの塊が乗り物にやってくることに驚かされることはありません。 私の懸念は、他の人の仕事と「技術をリードする」責任のレビュー/ペアリングから生まれます。そのため、対応する必要があると感じました。

「私たちは見なければならない」と私はそれをうまく要約していると思います（私は膨満感/誤用についてもっと冷笑的です）。

今夜はドラフトデザインを読みますが、これまでのところ、TinyGoの観点からは見栄えがします。

私はただ一つのことを明確にしたかった：

一方、 TinyGoやU-rootのようなプロジェクトは、ディスクやフラッシュよりも多くのRAMを搭載したシステムを対象としています。 これらのプロジェクトでは、アセットを圧縮し、実行時に増分解凍を使用すると、大幅な節約が可能になります。

U-rootについてはわかりませんが、TinyGoの主なターゲットは、通常RAMよりもはるかに多くのフラッシュ（通常は8または16倍）を備えたマイクロコントローラーです。 ドラフトデザインをざっと見てみると、ファイルを読み取り専用メモリに保持するというアイデアが示唆されているようです。これは、これらのターゲットでは問題なく機能します。埋め込みファイルはフラッシュから直接読み取ることができます。 TinyGoターゲットが実行時にファイルを解凍することはおそらく望ましくありません。

これが依存するio / fs提案は、＃41188および以前の＃40352で議論されているように、Readdir / FileInfoの問題でブロックされているように見えます。

https://github.com/golang/go/issues/41188#issuecomment-686283661でそれらを置き換えるAPIをドラフトしました

@andig

私が提案で見つけられなかったが必要なことの1つは、開発サイクル中に埋め込まれたファイルをライブリロードする機能です。

embed.Filesはfs.FSを実装しているため、dev vs！devビルドタグを使用して、embed.Filesと実際のFSの間で変数を切り替えるだけです。

＃41265を提出しました。 io / fs用の新しいReadDir（）APIを提供します。

@tristanfisherと同様の懸念が//go:embedがより一般的である可能性があります。 コンパイラ指令の別の構文を検討するときが来たのではないでしょうか。

Go構文の変更には非常に高いコストがかかることを思い出してください。 たとえば、新しい構文をサポートするには、そこにあるほとんどすべてのGoツールを更新または修正する必要があります。

私はそれらを魔法のコメントとは見なしません。 //go:始まる行はディレクティブであり、仕様でそのように定義できます。 //go:プレフィックスがすでに非として扱われていることを除いて、 //go:embed 、 @embed 、 [[embed]]またはその他の数の構文バリエーションの間に多くのセマンティックの違いはありません。 -Goツールによるコード。 （私の編集者は、たとえば、これらの行を異なる方法で強調表示します）

@mvdanこの提案が発生した場合、Goの構文が変更されています。 既存のツールを壊さない方法で変更されただけです。 多分それは衒学的に思えます。

@iandコンパイラ指令の特定の構文については

この提案は良い考えだと思います。 それは一般的な問題を解決します。 私の懸念は、それを採用するコストをもう少し明確にする必要があるということです。

@jonbodner魔法のコメントについてのあなたの懸念を共有します。 しかし、ある程度、ルールは＃37974で指定されています。

@networkimprov 、これはio / fsの提案ではありません。 ここでReadDirについてコメントするのをやめてください。

@jonbodner

コンパイラ指令の特定の構文については気になりません。 ある時点で形式化してルールを指定する必要があると思います。

Goツールチェーンディレクティブをマークするために//go:を使用することを決定したことを指摘しておきます。
2012年に（限定使用） //go:nointerfaceアノテーションを
2013年にアセンブリ作成者用に//go:noescapeを
2014年に//go:generateを
2020年から2021年にも//go:buildを可能性が
他にもあります。 それはただのハイライトです。
//go: 、役立つ場合はCからの#pragmaを意味すると考えることができます。

この時点で、大会は非常に確立されています。
2012年にその構文を選択したのは、
（1）それは明らかに人へのコメントではありません。
（2）コメントを知らないツールは、コメントであるため無視します。 と
（3）他のツール（s / go / yourtool /）に一般化します。

そして、イアンが言ったように、＃37974は、それが価値があるもののために、正確な一般化されたコメント構文を形式化しました。

上記の議論に基づくと、これはおそらく受け入れられるようです。
（繰り返しますが、FSの提案を想定していますが、それとは別です。）

コンセンサスに変更はないので、受け入れました。

埋め込みを手に入れたいと思っています。これはすでにマスターでテストできますか、それとも1.15サイクル中に実験として出荷する予定はありますか？

@ andig 、 リリースされています。 これがGo1.16にあり、今月開発ブランチに上陸することを願っています。

@rsc 1.16は利用できますか？

@septs 、Go1.16に取り組んでいます。 コードのフリーズは10月31日で、リリース予定日は2月1日です。

最速の2021Q1または2021Q2リリース？

@septsは、このスレッドでGoリリースについて質問するのをやめてください。 20人以上がそれをフォローし、通知を受け取ります。 https://golang.org/wiki/Questionsおよびhttps://github.com/golang/go/wiki/Go-Release-Cycleを参照して

変更https://golang.org/cl/243941はこの問題に言及しています： go/build: recognize and report //go:embed lines

変更https://golang.org/cl/243940はこの問題に言及しています： go/build: refactor per-file info & reader

変更https://golang.org/cl/243942はこの問題に言及しています： embed: implement Files

変更https://golang.org/cl/243944はこの問題に言及しています： cmd/compile: add //go:embed support

変更https://golang.org/cl/243945はこの問題に言及しています： cmd/go: add //go:embed support

実装レビューで浮かび上がった詳細の1つは、単数名詞としての「ファイル」はかなり扱いにくいということです（「ファイルは保持されます...」）。

名前のembed.Filesの選択は、io / fs提案と、文字列および[] byteのサポートの両方よりも前のものでした。
これらの開発の両方を考えると、「ファイルが保持されている」問題を解決するための1つの一見賢明な方法は、ファイルではなくFSと呼ぶことです。

次に、データを埋め込んで印刷する3つの方法は次のとおりです。

import "embed"

//go:embed hello.txt
var s string
print(s)

//go:embed hello.txt
var b []byte
print(string(b))

//go:embed hello.txt
var f embed.FS
data, _ := f.ReadFile("hello.txt")
print(string(data))

文字列、[]バイト、またはFSなど、何が得られるかについてはより明確に思えます。
つまり、embed.F *の機能のほとんどは、fs.FSであることに由来しており、FSと呼ぶと、ファイルと呼ぶよりも明確になります。

CL実装パッケージ埋め込みの最新ドラフトでその変更を行いましたが、ここに戻って、名前の変更に異議があるかどうかを確認したいと思いました。

（より根本的な変更は、 var f embed.FS var f fs.FS代わりにvar f embed.FSを実行することですが、これにより、Open以外のfメソッドを使用できなくなります。たとえば、上記のように、 ReadFileは便利であり、不可能です。一般に、後でメソッドを追加する可能性のあるものに具象型を使用することは、インターフェイス型を直接使用するよりも将来性が高いことを学びました。）

名前の変更は良い変更だと思います。

より根本的な変化に関して：

• fs.FS使用する場合、 embedパッケージも必要になりますか？ 動的な値にはまだ何らかのタイプが必要だと思いますが、それは何らかのパッケージに含まれていますか？ パッケージを追加する必要がないという考えはプラスです。
• 私はIMOので、スーパー説得「我々はメソッドを追加することはできません」が見つかりませんf.ReadFile(…)大幅に少ないよりも便利ではありませんfs.ReadFile(f, …) 。
• ただし、一般的には具象型の方が優れていることに同意するので、それを維持するのはプラスですembed.FS
• 別の質問： embed.FSはポインターレシーバーを使用しますか、それとも値レシーバーを使用しますか？ IMOが&fを渡さなければならないのは厄介で、バリューレシーバーを使用するのは少し予想外です。 ただし、 var f *embed.FSも許可する場合があります。 変数にインターフェイスタイプがある場合、この質問はなくなります。

全体として、私はまだ具体的なembed.FSを使用する方が良いことに同意します-他に何もないとしても、文書化の目的で。

あなたがそれについて言及したので、私はこれを明確にしたとは思いません：私たちはディレクトリを正しく埋め込むことができますか？

はい、fs.FSを実装するembed.FSとして。

@ Merovius 、embed.FSはバリューレシーバーを使用します。 embed.FSは、単一のポインターを含む1ワードの構造体であるため、実際のオーバーヘッドはありませんが、どこにでも*や\＆sを気にせずに、それらを割り当てて使用できることを意味します。

@ chabad360 、はい、ディレクトリを埋め込むことができます。

シンボリックリンクはどうですか？

@ burik666 、詳細についてはhttps://golang.org/s/draft-embed-designを参照してください。ただし、シンボリックリンクを埋め込むことはできません。

動的Cライブラリを埋め込んで使用することは可能ですか？ もしそうなら、次のような#cgoヘッダーの埋め込みパスをどのように使用しますか？ #cgo LDFLAGS: -L./lib -lmylib -Wl,-rpath=./lib ？

@benitogfこれを行う唯一の実際の方法は、ディスクに書き込んでdlopenを使用することだと思います。 埋め込みファイルを見つける方法をダイナミックローダーにどのように伝えることができるか想像できません。 また、Cコードにバンドルしたい場合は、とにかく静的リンケージの方が適切だと思われますね。

@benitogf埋め込みを使用すると、ファイルをディスクからプログラムの[]バイトに簡単に配置できます。
[]バイトの形式でプログラムにすでに存在する動的Cライブラリを使用する方法がある場合、埋め込みはそこにディスクファイルを取得するのに役立ちます。 それ以外の場合はありません。

とにかく静的リンケージの方が適切だと思いませんか？

@Meroviusは同意しましたが、動的ライブラリのみを提供するベンダーと協力するいくつかのユースケースがあります

[]バイトの形式でプログラムにすでに存在する動的Cライブラリを使用する方法がある場合
これを行う唯一の実際の方法は、それらをディスクに書き込んでdlopenを使用することです。

組み込みライブラリを[] byteからファイルシステムに書き込み、dlopenを使用することは問題ないようですが、ビルド/実行時に組み込みファイルをファイルシステムにオプションで「ダンプ」して、 #cgoヘッダーがそれらにアクセスできるようにすることは便利です。 cgoimhoの場合

今これを試してみてください。 1個のいぼgo:embedディレクティブは、私が埋め込む場合ということですbuild/*ファイル名がまだ接頭持って、 build/ 。 その後、 http.FSを介してそのディレクトリを提供したい場合、必要に応じてそれらにアクセスするために必要なプレフィックスを_追加_する簡単な方法はありません（ラッパーを作成しないと、すべての潜在的なメソッドをリストする必要があるという問題が発生します） FSが持っているかもしれない...）。

例えば：

//go:embed build/*
var buildDir embed.FS

// Serve some SPA build dir as the app; oops, needs to be build/index.html
http.Handle("/", http.FileServer(http.FS(buildDir)))

// or

//go:embed static/*
var staticDir embed.FS

// Oops; needs to have a static prefix.
http.Handle("/static/*, http.StripPrefix("/static", http.FileServer(http.FS(staticDir))))

// Could be this, but only because the prefix happens to match:
http.Handle("/static/*, http.FileServer(http.FS(staticDir)))

go:embed foo/* bar/* baz.extを書き込んでそれらのファイルをすべて取得できるようにすることを目的としていますが、ディレクトリを埋め込んでhttpパッケージを介して静的アセットとして提供することは非常に一般的だと思います。 プレフィックスがすでに処理されているhttp.Dir("static")やpkger.Dir("/internal/web/static")ようなものから、新しいembed.FS切り替えるので、これは落とし穴になると思います。

embed 、 io/fs 、およびnet/httpとの相互作用のようなものであるため、これをファイルする方法がよくわかりません。

@zikaeroh http.Handlerラッパーを書くこともそこではうまくいくでしょうか？ これはたった1つの方法であり、 http.HandlerFuncます。 おそらく、標準ライブラリはhttp.StripPrefix （ http.AddPrefixやhttp.ReplacePrefix ）をミラーリングするライブラリを提供することもできます。

潜在的には、FS実装を回避するためにHTTPリクエストを変更するのは少し奇妙に感じますが（オプションのメソッドでは単純ではない一般化された「別のFSのサブディレクトリであるFSを教えてください」とは対照的です）。 これは最も効率的な方法ではありません。削除してから別のプレフィックスを再度追加します（ http.Requestコピーの場合）が、後で試してみます。 少なくとも、リクエストを処理する必要がある現在のスキームとは_違いはない_と思います。

httpパッケージを介さずに静的データを使用する場所が他にもいくつかあり、同様の修正を行う必要があります。

それがどのように実装されているかを見る必要がある場合は、どこを見ることができますか。 それが実装されているブランチ？

以前は、ファイルをインプレースで埋め込むこと、つまりビルドディレクトリに埋め込んでからインポートすることをお勧めしました。 これにより、ビルドプレフィックスが削除されます。 次に、ハンドラーを使用して必要なプレフィックスを追加します。 埋め込みを行うgoファイルをそれ自体の埋め込みから除外する方法がわかりません。 https://github.com/golang/go/issues/41191#issuecomment-686621090を参照して

以前は、ファイルをインプレースで埋め込むこと、つまりビルドディレクトリに埋め込んでからインポートすることをお勧めしました。 これにより、ビルドプレフィックスが削除されます。 次に、ハンドラーを使用して必要なプレフィックスを追加します。 埋め込みを行うgoファイルをそれ自体の埋め込みから除外する方法がわかりません。 ＃41191（コメント）を参照

残念ながら、これは他のツールで作成されたディレクトリ、たとえばwebpackビルドやCRAの出力（事前にクリーンアップされ、チェックインされていないことが多い）には適していません。 ファイル名をハックしたいです。

以前は、ファイルをインプレースで埋め込むこと、つまりビルドディレクトリに埋め込んでからインポートすることをお勧めしました。 これにより、ビルドプレフィックスが削除されます。 次に、ハンドラーを使用して必要なプレフィックスを追加します。 埋め込みを行うgoファイルをそれ自体の埋め込みから除外する方法がわかりません。 ＃41191（コメント）を参照

残念ながら、これは他のツールで作成されたディレクトリ、たとえばwebpackビルドやCRAの出力（事前にクリーンアップされ、チェックインされていないことが多い）には適していません。 ファイル名をハックしたいです。

webpackのような巨大なプラグインシステムを使用している場合は、別のwebpackプラグインをインストールするだけで、アセット自体に沿ってembed.goを生成するのは簡単です。 makefileまたはシェルスクリプトでより単純なものを使用している場合は、そこから.goファイルを生成することも簡単です。

@zikaeroh

一般化された「別のFSのサブディレクトリであるFSを教えてください」とは対照的に、これはオプションのメソッドでは単純ではありません。

シンプルなはずです。 ラッピングの問題の処理は、設計プロセスの一部でした。 特に、ラッパーは、 fsで適切なヘルパー関数を呼び出すだけで、すべてのオプションのメソッドを実装することになっています。 それがうまくいかない場合は、それが心配であり、いくつかの詳細を取得するのは素晴らしいことです。

また、IMO、そのようなラッパー（プレフィックスを取り除く）の実装は、最終的にio/fs （ io.LimitWriterなどに類似）によって提供される必要があります。 それがまだ起こっていない唯一の理由は時間だと思います。

@andigこれを行う際の問題は、embed-directiveと変数を含むGoファイルがFSからも表示されることです（HTTPによって提供されるか、別の方法で公開される可能性があります）。

これを行う際の問題は、embed-directiveと変数を含むGoファイルがFSからも表示されることです（HTTPによって提供されるか、別の方法で公開される可能性があります）。

これを修正する1つの方法は、特定のファイル/フォルダーを埋め込みから除外する機能を追加することです（ @rsc ？）

これを修正する1つの方法は、特定のファイル/フォルダーを埋め込みから除外する機能を追加することです（ @rsc ？）

この提案は1か月以上前に受け入れられ、すでに実施されています。 現時点では、パスを除外できるなどの大規模な設計変更は合理的ではないと思います。 実装された設計に問題があり、回避できない場合は、詳細を記載した別のバグレポートを提出することをお勧めします。このレポートは、最終的な1.16リリースの前に追跡できます。

@Merovius

シンプルなはずです。 ラッピングの問題の処理は、設計プロセスの一部でした。 特に、ラッパーは、fsで適切なヘルパー関数を呼び出すだけで、すべてのオプションのメソッドを実装することになっています。 それがうまくいかない場合は、それが心配であり、いくつかの詳細を取得するのは素晴らしいことです。

Globのプレフィックスストリッピングはどのように機能しますか？

@icholy私は次のようなものを想定しています

func (f *stripFS) Glob(pattern string) (matches []string, err error) {
    matches, err = fs.Glob(f.wrapped, path.Join(f.prefix, pattern))
    for i, m := range matches {
        matches[i] = strings.TrimPrefix(m, f.prefix+"/")
    }
    return matches, err
}

たぶん、いくつかの追加の注意が必要です。

gotipでこれを試してみると、.DS_Storeファイルが含まれていることがわかります。 これは避けられないことだと思いますが、ドットファイルを含めると誤ってファイルが含まれるのではないかと心配しています。 たぶん、ドキュメントはこれについて強い警告を持っているはずですか？

私のシェルは*にドットファイルを含めていないので、それらを含めたい場合は* .*を使用する必要があります。 これは、あるレベルの制御を与えるための（おそらく同様に驚くべき）方法かもしれません。

何を考えるべきかわかりません-IMO、ドットファイルはパターンによって実際に異なって扱われるべきではありませんが、OTOH .DS_Store例は本当に対処されるべきもののようです。

なぜgit clean -dffx && go buildだけをしないのですか？ DS_Storeファイルがgitにある場合、それらはビルドに含まれます。 そうでなければ、そうではありません。 これはgitignoreでもうまく機能します。

とにかく、クリーンなVCSチェックアウトでビルドする必要があります。 ランダムな一時ファイルを追加すると、最終ビルドに組み込まれる可能性があり、最終的にどのファイルになるかわからない可能性があります。 これを文書化することをお勧めします。

@mvdan原則的には同意しますが、実際には、警告がない場合、多くの人がダーティビルドによって火傷を

再：http.FileServersを埋め込む

webpackのような巨大なプラグインシステムを使用している場合は、別のwebpackプラグインをインストールするだけで、アセット自体に沿ってembed.goを生成するのは簡単です。

それは本当ですが、それは非常に厄介です。 embed.FSのポイントは、クレイジーなMakefile回避策の必要性を減らすことです。 簡単な解決策は、FSをサブディレクトリにロックするfs.WithPrefix(string) fs.FSを用意することだと思います。 提案の中でこれについての議論があると思いましたが、今は見つかりません。 たぶんそれはRedditか何かでただ動揺しただけです。

これを修正する1つの方法は、特定のファイル/フォルダーを埋め込みから除外する機能を追加することです（ @rsc ？）

それは次のようなものかもしれません

//go:embed static
//go:embed-exclude .*
var staticFiles embed.FS

embed-excludeディレクティブは、受け入れられたファイルに対してglobフィルターを実行し、一致するものをすべて削除することができます…

この提案にこれ以上追加することを避けたい場合は、組み込みファイルシステムに予期しないドットファイルがないかチェックし、ビルドを修正してそれらを削除できるように警告するlintルールにすることもできます。

または、。*などを追加して特に言及されていない限り、デフォルトでドットファイルを除外します。

それでも、assets.goファイルの公開は処理されません。 すでに実施されている提案については、議論の段階で資産生成についての質問が出されたことに注意してください。 （embedディレクティブを除いて空の）assets.goを公開することはおそらく危険ではありませんが、公開しない方がクリーンです。 いつものように、適用できるあらゆる種類の回避策があります。

（embedディレクティブを除いて空の）assets.goを公開することはおそらく危険ではありませんが、公開しない方がクリーンです。

私は、これが問題になることは非常にそうであることに同意、私は、我々が正しく設定]のものに簡単にそれを作ることができれば、誤って設定ミスが原因で漏れた任意のクローズドソースコードを見ることが嫌いです。

誰かが自分の.envファイルが誤って埋め込まれていることに気づかなかった秘密のリークを見たくありません。

誰かが//go:embed static/*を使用していて、 static/.envまたはstatic/.super-secretがある場合、ユーザーは本当にそれらのファイルを含めるつもりだったと思いませんか？ そうでなければ、なぜそれらは静的ディレクトリにあるのでしょうか？

これはユーザーが期待するものであり、ほとんどのコンテキストで*が何を意味するかによると思いますが、個人的にはhttps://golang.org/pkg/path/filepath/#Globセマンティクスが唯一の良い点だと思いますオプション。 これは最も単純で、ほとんどのGoユーザーがGoの開発のコンテキストで慣れているものです。

いずれにせよ、 *を埋め込むことの危険性に対する警告は良い考えだと思います。なぜなら、かなりの数の場合、 *.pngようなより具体的なグロブを使用することでエラーの可能性を減らすことができるからです。 。

また、バグレポートの観点から書かれた、1.16リリースに対して追跡できる別の問題を提出することをお勧めします。 この提案は受け入れられ、実行されているので、まもなく終了すると思います。 たとえば、バグレポートを次のように表現できます。埋め込みファイルのサポートにより、意図しないファイルが簡単に含まれるようになります（いくつかの例を示します）。

誰かが// go：embed static / *を使用していて、static /.envまたはstatic / .super-secretがある場合、ユーザーは本当にそれらのファイルを含めるつもりだったと思いませんか？ そうでなければ、なぜそれらは静的ディレクトリにあるのでしょうか？

たとえば、vimで編集セッションを開いたが閉じなかった場合、誰にも見られたくないコンテンツを含む.*.swpファイルが作成されたなど、非常に多くのコーナーケースがあります。

ディスカッションを＃42321に移動します。

これは、 Database GoクライアントのPrismaチームに高く評価されます。これは、実行時に錆で記述され、何らかの方法でビルドされたgoバイナリに含める必要があるクエリエンジンを使用するためです。

現在行っている方法は、go：generate時にバイナリを.goファイルにパックすることですが、ファイルサイズはバイナリの.gzファイルの場合よりもはるかに大きくなります。

ネイティブ埋め込みはこれをはるかに改善するので、.gzファイルを最終的なgoバイナリに直接埋め込むことができます。

誰かが//go:embed static/*を使用していて、 static/.envまたはstatic/.super-secretがある場合、ユーザーは本当にそれらのファイルを含めるつもりだったと思いませんか？

いいえ、しません。

$ mkdir z
$ touch z/.secret z/intended
$ ls z/*
z/intended
$ ls z
intended

https://github.com/golang/go/issues/42328#issuecomment-720169922にある私の後のコメントを参照して

静的ファイル/テンプレートを埋め込み可能にして、開発者の生産性を大幅に向上させるというアイデアが大好きです。

しかし、コメントであるはずのこの//を再利用する以外に、別のタグ（ @など）を革新する必要がありますか？

今のところ、 //は使いすぎていると思いますが、次のことを考えてみてください。

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:webhook:verbs=create;update,path=/validate-batch-tutorial-kubebuilder-io-v1-cronjob,mutating=false,failurePolicy=fail,groups=batch.tutorial.kubebuilder.io,resources=cronjobs,versions=v1,name=vcronjob.kb.io
// +optional
...

しかし、コメントであるはずのこの//を再利用する以外に、別のタグ（ @など）を革新する必要がありますか？

これは別の議論であり、ディレクティブがコメントではないのは良いことですが、多くのgo1互換コードはすでにそれに依存しているため、変更されない可能性があります。

しかし、コメントであるはずのこの//を再利用する以外に、別のタグ（ @など）を革新する必要がありますか？

私はそれを見つけようとしましたが失敗しましたが、これらの種類のディレクティブについて//go:<word>で標準化する決定があったことを覚えています。
構文を明示的に収束するという決定を考えると、構文を変更するのは良い考えではないようです。
（もちろん、これらはコンパイラが無視するように特別にコメントされています。これらのディレクティブはgoツールに固有であるため、適切な言語に漏れないようにする必要があります）

io/fs問題について、 embed.FSがETagをサポートしているという言及を見ました： https ：

テストを実行しようとしましたが、 ETag応答ヘッダーセットが表示されません。 多分私は使用法を誤解しています。 ここで見られると思いますか？ https://play.golang.org/p/Wq5xU5blLUe

そうは思わない。 http.ServeContent （ http.FileServer ）はETagヘッダーを検査しますが、AIUIでは設定されません。

上記のコメントで、 RussはETagが機能するようになると述べています。 難しいのは、 embed.FS ETagまたは他のキャッシュヘッダーを設定するために必要な情報をhttp.FileServer通信させる方法です。 これには、おそらく別の追跡の問題があるはずです。

個人的には、 embed.FSは、関連するモジュールの最後のコミットの時間をModTimeとして使用する必要があると主張します。 これはおおよそdebug.BuildInfoに対応するため、再現性に影響を与えることはありません。 タグ付けされたリリースに対応しないコミットに対してそれがどのように設定されているかはわかりませんが、ダーティワークツリーからのビルドに対して何に設定するかについては疑問が残ります。

しかし、私は@rscが良い解決策を念頭に置いていると

「コミット時間」についてのコメントがよくわかりません。 モジュールソースがzipファイルの場合、「コミット」はありません。 debug.BuildInfoまたはdebug.Moduleに記載されている時間はありません。

さらに重要なことに、タイムスタンプベースのメカニズムは、適切な（コンテンツベースのハッシュ）etagよりも厳密に劣っていると私は主張します。

@ tv42すべてのモジュールバージョンは、a）タグから派生したセマンティックバージョン（コミットを指す）またはb）コミットハッシュを含む疑似バージョンのいずれかです。 私が思うに？ 少なくともgitでは。 私は何かを誤解しているかもしれません。

さらに重要なことに、タイムスタンプベースのメカニズムは、適切な（コンテンツベースのハッシュ）etagよりも厳密に劣っていると私は主張します。

私はちょっと確信が持てません。 ハッシュを通信するためにサイドチャネルが必要であるか、サーバーが要求に応じてファイルのハッシュを計算する必要があります（これはかなり高価に思えます）。 結局のところ、 net/httpは、 fs.FS内容が変更される可能性があるかどうか、事前に知りません。 ハッシュベースのETagの最終結果は、そのようなサイドチャネル（オプションのインターフェイスなど）を追加するコストを正当化する可能性がありますが、明らかに厳密に

また、少なくとも時間ベースのアプローチもサポートすることは、より多くのクライアントと連携できることを意味すると私は主張します。 ただし、それをサポートするデータはありません（つまり、 If-Modified-Sinceサポートしているが、 ETagをサポートしていないクライアントが存在するかどうか、またその数はわかりません）。

しかし、実際には、どちらのアプローチを選択するかはあまり気にしません。 モジュールバージョンがタグ付けされた時間を使用するオプションについて言及したかっただけです。

@Merovius Goモジュールは、zipファイルで指定されます。 Gitが、仕様を変更しない構築に使用される一般的なソースであるという事実。 zipのタイムスタンプはゼロです。

$ unzip -v ~/go/pkg/mod/cache/download/golang.org/x/crypto/@v/v0.0.0-20200510223506-06a226fb4e37.zip|head
Archive:  /home/tv/go/pkg/mod/cache/download/golang.org/x/crypto/@v/v0.0.0-20200510223506-06a226fb4e37.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
     345  Defl:N      233  33% 1980-00-00 00:00 237856c8  golang.org/x/[email protected]/.gitattributes

付随する*.infoファイルにタイムスタンプがあるようですが、それが信頼できるのか、ツールで利用できるのかわかりません。

$ cat ~/go/pkg/mod/cache/download/golang.org/x/crypto/@v/v0.0.0-20200510223506-06a226fb4e37.info; echo
{"Version":"v0.0.0-20200510223506-06a226fb4e37","Time":"2020-05-10T22:35:06Z"}

それでも、どのタイムスタンプを使用する必要がありますか：メインモジュール（ go buildを実行するモジュール）に使用を埋め込みますか？

個人的には、バイナリに不変に埋め込まれている静的ファイルのコンテキストでは、ハッシュはあらゆる点でタイムスタンプよりも優れているように見え（ETagが存在する前のレガシーサポート、HTTP / 1.1以前、90年代を除く）、分散システムと並行ビルドのどちらかで混乱が生じます。 私はETagを理解していないクライアントがもう存在しないことを真剣に疑っています、そして彼らは確かにHTTP / 2移行をしません。

ハッシュを伝達するためのサイドチャネルは、私には正しいことのように思えます。 ファイルのハッシュを返すオプションのFSインターフェイス。 （そして、特定のハッシュアルゴリズムを要求する別の方法がありますか？。一部のサービングのユースケースでは、「いくつかのハッシュ」だけでなく、sha256 / sha1 / md5が本当に必要です）。 十分に安価な答えがないFSは、それを実装しないことを選択できます。

（最近のハッシュは、暗号的に安全な場合でもギガバイト/秒/コアですが、安全性の低いハッシュの場合は数十ギガバイト/秒であり、統計呼び出しに基づいて簡単にキャッシュできます。どこでもETagをサポートするだけです。）

私は今日この提案について考えていました。 この機能がGoツールチェーンに含まれていることを嬉しく思います。また、これまでの提案に寄せられたすべての考えと努力に感謝します。 これを提案し、これを前進させてくれてありがとう。

2つの質問があり、次に1つの提案があります（これは提案のディスカッション期間を過ぎており、すでにリリースがフリーズしていることを認めています）。

許可されるタイプ

現在のコードでは、変数が正確に〜 embed.FS 〜、 string 、または[]byteとして宣言されていることを想定していることに気付きました。 特に、これらは許可されていません： []uint8 、〜 FS 「埋め込み」のドットインポート後〜、またはタイプエイリアスを使用して構築された他の同一のタイプ。 （編集：ドットインポートがgc内でどのように機能するかを忘れ、 embed.FSを検出するためのコードを読み間違えました。）

これは意図されたものですか、それともバグですか？

[]byte型変数のセマンティクス。

[]byte型変数の予想されるIDセマンティクスが何であるかについての言及はありません。 特に、関数スコープの変数の場合。 これは、 string embed.FS型変数と[]byte型変数の意図されたセマンティクスを知ることは重要です。

現在の実装では、以下のテストプログラムはfalse true （ foo.txtが空でない場合）。 それは意図された/保証されていますか？

package main

//go:embed foo.txt
var a []byte

//go:embed foo.txt
var b []byte

func f() *byte {
    //go:embed foo.txt
    var x []byte
    return &x[0]
}

func main() {
    println(&a[0] == &b[0], f() == f())
}

//go:embed変数のGoに似たセマンティクスは、複合リテラルのセマンティクスであると思います。つまり、実行するたびに新しいコピーが生成されます。

これに対する適切なセマンティクスについてコンセンサスがない場合は、いつでもパントして関数スコープを作成できます。 []byteタイプはGo 1.16のエラーを埋め込みます。ユーザーは、パッケージレベルの変数を宣言できます。現在のセマンティクス（ソース宣言ごとに1バイトスライス）が必要な場合、またはstring型の変数を使用して、複合リテラルセマンティクスが必要な場合は[]byte変換します。 その後、ユーザーがより多くの恩恵を受ける行動を後で再検討することができます。

より多くの//go:ディレクティブを回避する

プログラムのセマンティクスに影響を与えるエンドユーザーに//go:ディレクティブを追加しないことをお勧めします。また、通常のGo構文よりも//go:embedを優先するための引数が見つかりません。 Go 1.16のリリース前に、この決定を再検討することをお勧めします。 （繰り返しになりますが、このリクエストがどれだけ遅れているかを感謝します。）

まず、

//go:embed foo.txt bar.txt
var x embed.FS

に

var x = embed.Files("foo.txt", "bar.txt")

同様に、関数embed.Bytesおよびembed.Stringを使用して、単一のファイルを埋め込み、 []byteまたはstring値として取得できます。

反応

同様に、embed.Files変数は、コンテキストでより便利なものに応じて、グローバル変数またはローカル変数にすることができます。

embed.Filesなどがあると、式のコンテキストでも使用できます。これはさらに便利な場合があります。

「embed」をインポートしないソースファイルで// go：embedを使用するとエラーになります（このルールに違反する唯一の方法は、型エイリアスのトリックです）。

embed.Filesなどの場合、これはパッケージ埋め込みによってエクスポートされる関数によるエラーです。

Goimports（およびgoplsなど）はこのルールを教えられ、必要に応じて// go：embedを使用して任意のファイルにインポートを自動的に追加できます。

「埋め込み」のインポートがembed.Filesなどの使用を修正する適切な方法であることを認識するために、特別なgoimportsまたはgoplsロジックは必要ありません。

このアプローチは、型チェックの問題を修正します（完全な言語変更ではありません）が、それでも実装はかなり複雑です。

特に、 CL276835はコードのネット削除です。 特に、コンパイラコード（gccgoや他のコンパイラで再実装する必要があります）ははるかに単純です。

私はまた、の微妙なセマンティクスについてのティーチGO /タイプに容易になります期待してembed.Filesについて、それを教えることよりも、（彼らは唯一の文字列リテラルの引数を受け入れること、すなわち）、など//go:embed 。

goコマンドは、Goソースファイル全体を解析して、埋め込みに使用できるようにする必要のあるファイルを理解する必要があります。 今日では、インポートブロックまで解析するだけで、完全なGo式は解析しません。

CL 276835では、動作はヒントと同じです。goコマンドは、パッケージ埋め込みをインポートするファイルのGoソースファイル全体を解析し、そうでないファイルのインポートのみを解析します。

確かに、埋め込みをインポートするファイルの場合、CL 276835は完全な解析とウォークを実行しますが、tipは//go:embedコメントに対してより効率的な文字列スキャンを実行します。 embed.Files呼び出しを見つけるための、より最適化されたワンパスアルゴリズムは、必要に応じて実行可能だと思います。

また、これらの特別な呼び出しの引数にどのような制約が課されているかもユーザーにはわかりません。通常のGo呼び出しのように見えますが、文字列リテラルのみを取得でき、Goコードによって計算された文字列は取得できず、名前付き定数（またはgoコマンドには、完全なGo式エバリュエーターが必要です）。

これは、私には//go:embedディレクティブと実質的に異なるようには見えません。ユーザーは、最初に使用するまで、そこで使用できる引数を期待していません。 さらに、どちらの方法でも、ユーザーが誤って使用するとコンパイラエラーメッセージが表示されますが、IDEやその他のツールは、 embed.Filesなどのより優れたgodocsと相互参照を自動的に提供します。

@mdempsky FSのドットインポート後にembed同じタイプです。 したがって、その特定のケースは単純な「はい、それで問題ありません」のように見えます（試してみて、すでに機能しています）。 同様に、 byteはuint8エイリアスであるため、 []uint8も[]byteと同じタイプですが、意外なことに、これは現在

// go：embed変数のよりGoに似たセマンティクスは、複合リテラルのセマンティクスであると思います。つまり、実行するたびに新しいコピーが生成されます。

私は同意する傾向があります、それは私の期待でもありました。 最初は、これはエスケープ分析のアーティファクトであり、コンパイラはデータを変更しないことに気付いたのではないかと思いましたが、そうではありませんでした。

func f() {
    //go:embed foo.txt
    var x []byte
    fmt.Printf("%q\n", x)
    x[0] = 'x'
}

func main() {
    f()
    f()
}

ただし、「すべてのvar宣言で新しい変数が作成される」という問題もあります。これは、このようなコードを意味するためです。

func ServeIndex(w http.ResponseWriter, r *http.Request) {
    //go:embed "index.html"
    var x []byte
    http.ServeContent(w, r, "index.html", time.Now(), bytes.NewReader(x))
}

不必要に割り当ててコピーします。 おそらくそれは問題なく、より明確なセマンティクスの利点よりも重要です。 しかし、おそらくそれは、あなたが言及しているように、ローカルの[]byte埋め込みを禁止する兆候でもあります。

また、// go：embedについて教えるよりも、embed.Filesなどの微妙なセマンティクスについてgo / typesを教える方が簡単だと思います（つまり、文字列リテラル引数のみを受け入れる）。

Go型システムでは、少なくとも文字列定数のみを実行できます。

しかし、 go/typesは、 //go:embed使用して、埋め込みファイルについて知る必要さえありますか？ 結局のところ、これらの変数のタイプはかなり明確です（前述のように、ローカルの[]byte埋め込みを除きます）。

//go:embed "foo"
var x []byte

これは本当に変更可能であることを意味しますか？ 静的アセットを埋め込みたいという単一のユースケースは考えられませんが、実行時に変更するので、バグが有効になるだけだと思います。 私はそれを.rodata押し込んで、何かがそれを変異させようとするとパニックに陥ったほうがよかったでしょう。

（上記のx[0] = 'x'によって促されます。）

@Meroviusは書いた：

@mdempsky FSのドットインポート後にembed同じタイプです。 したがって、その特定のケースは単純な「はい、それで問題ありません」のように見えます（試してみて、すでに機能しています）。

ありがとう。 コンパイラ内でドットインポートがどのように機能するかを忘れたため、コードを読み間違えました。 その例を含める前に、最初に試してみるべきでした。

ただし、今のところ、実装されているセマンティクスは問題ないと思います。必要に応じて、後でいつでもより多くの型やエイリアス、さらには「同じ基になる型」​​を許可できます。

[]byteと[]uint8は、型エイリアスを使用して構築された他の無数の型と同様に、Go仕様では同一の型です。 コンパイラがembed.Files("foo" + ".txt")をembed.Files("foo.txt")とは異なる方法で処理することが受け入れられない場合は、同じ引数を拡張して、エイリアス型を異なる方法で処理できないようにする必要があります。

しかし、 go/typesは、 //go:embed使用して、埋め込みファイルについて知る必要さえありますか？

いいえ、 embed.Filesの特別なセマンティクスについても知る必要がないのと同じように、そうする必要はありません。 ただし、どちらの構文でも、誤用について警告できるgo / typesには価値がある可能性があります。

-

@ tv42は書いた：

これは本当に変更可能であることを意味しますか？

明らかに。 Goコンパイラは、 stringとembed.FS埋め込みを重複排除して、rodataに配置するように特別に調整しますが、 []byte埋め込みはそうではありません。

https://github.com/golang/go/blob/56b783ad94f9a55163d494d5b34c783a9603d478/src/cmd/compile/internal/gc/embed.go#L224

しかし、その提案がこの点に対処していないように思われるのは事実です。

思いやりのあるコメントをありがとう。 フォローアップするために2つの問題を提出しました。

＃43216-ローカル変数へのディレクティブの埋め込みのサポートを削除
＃43217-// go：embedで使用する必要がある文字列型とバイト型のエイリアスを定義します

// go：embed構文自体については問題を提起しませんでした。 なぜここで言いたかったので、私がそれを却下しているように誰にも見えないように。

提案プロセスについてブログをオープンな意思決定」の投稿でした。 投稿全体を読む価値はありますが、ここで再考のセクションを引用します。

オープンな意思決定の最後のルールは、重要な新しい情報がない限り、決定を再考しないようにすることです。 このルールには2つの部分があります。 まず、重大な意味で間違っていることが判明した決定を修正する準備をする必要があります。 これは特にスタートアップに当てはまります。多くの決定は完全な情報なしで行われなければならず、必然的にそれらのいくつかは間違っていることが判明します。 迅速に修正された誤った決定は、ほとんどまたはまったく損害を引き起こしませんが、修正されなかった誤った決定は壊滅的である可能性があります。

一方、最初の決定がなされてから重要な新しい情報が明らかにならない限り、決定を再考するべきではありません。 新しい情報が利用できない場合は、決定を再検討すると、おそらく元の決定と同じ結果が得られ、全員の時間が無駄になります。 決定が下されてから数週間後に従業員が私に来ることは珍しいことではありません。これを再考してください。」 私の答えは「あなたはどんな新しい情報を持っていますか？」です。 答えが「なし」の場合、再考はしません。 このような状況では、議論中に提示された議論の記録を残すことが役立つので、新しい情報が本当に新しいことを確認できます。 意思決定を再開するのが簡単すぎると、最終的な意思決定が行われず、従業員は永続的であるとは思わないため、意思決定の実施をためらうことになります。

あまり多くの決定を再考しないようにしたい場合は、意思決定プロセス中に広く意見を収集するようにしてください。 十分な入力が得られない場合は、決定後に重要な新しい入力が発生する可能性が高くなります。つまり、再検討する必要があります。 入力を収集するのに良い仕事をしている場合、決定を再検討する必要がある可能性ははるかに低くなります。

これは本当に私に共感しました：Go提案プロセス（一般に大規模なオープンソースプロジェクトのように）は、作業容量よりもはるかに高い提供負荷を持つシステムであるため、（必要に応じて同意せずに）コミットして次の決定に進むことが重要です。

stringと[] byteは、最初のフィードバックに応じて、この問題を検討するプロセスのかなり遅い段階で追加されましたが、これらの影響をすべて考慮していなかったことは明らかです。 そこで、私はこれら2つの新しい問題、＃43216と＃43217を提出しました。

一方、// go：embed構文は元の議論の中核部分であり、賛否両論で広く議論されました。 その構文を完全に再考する「重要な新しい情報」があるとは思わないので、前進し、再考に関するOusterhoutのアドバイスを念頭に置いて、それを脇に置いておきます。

文字列と[]バイトの問題を指摘していただき、ありがとうございます。

明らかに。 Goコンパイラは、 stringとembed.FS埋め込みを重複排除して、rodataに配置するように特別に調整しますが、 []byte埋め込みはそうではありません。

@rscたまたまこの最後の点について考えましたか？ 現在の実装では、より良いバイナリを生成するために、[] byteの代わりにstringを使用することが「ベストプラクティス」になる可能性があります。 それで大丈夫ですか？

なぜそれが「ベストプラクティス」になるのかわかりません。 私にとって、これはセンチネルエラーを定数にすることが「ベストプラクティス」であると言っているのと似ています。エラー型のパッケージスコープの変数を許可するべきではありません。それは良い習慣であり、追加の制限としての両方に同意しません。解決。

ローカル変数でstringのみを使用するという引数を見ることができました。 しかし、パッケージスコープの変数では、セマンティクスは明確で明確に定義されており、他の[]byte変数を使用するよりも、 []byte埋め込みを使用することはお勧めしません。

@mvdan 、ベストプラクティスとして[]byteではなくstringを使用することに偏っている場合は、それは良いことだと思います。 stringは、「不変のバイト文字列」に適したGoタイプですが、 []byteは、「可変のバイト文字列」または「不確定なバイトの文字列」に適したタイプです。

タイプstring （不変）の値があり、それをタイプ[]byte （不確定）として使用したい場合は、すでにunsafeを使用して正しく実行できます。 。 （たとえば、私のunsafeslice.OfString参照してください）。 おそらく、その操作でサポートされている標準ライブラリを追加する必要がありますが、それは別の提案のようです。

したがって、値を読み取り専用にする場合は、常にタイプstring使用するのが適切なようです。

@Merovius @bcmillsあなたは良い点を挙げています、そして明確にするために私は反対しません。 最終リリースの前に、プロポーザルの設計者がこの違いについて考えていることを確認したいと思います。

実際には、重複排除があまり発生しないと思います。 （複数のパッケージがまったく同じファイルを埋め込むのはどのような設定ですか？）一般的にはそうは思わないので、「文字列はバイナリが小さいことを意味します」と心配することなく、必要なフォームを使用する必要があります。

何人かの人々がETagについて尋ねました。 そのための時間がなくなりましたが、 https：//github.com/golang/go/issues/43223で提案を提出しました

＃43216と＃43217を提出していただきありがとうございます。 それらが受け入れられれば、 //go:embed提案に関する私の未解決の懸念に実質的に対処するでしょう。

一方、// go：embed構文は元の議論の中核部分であり、賛否両論で広く議論されました。 その構文を完全に再考する「重要な新しい情報」があるとは思わないので、前進し、再考に関するOusterhoutのアドバイスを念頭に置いて、それを脇に置いておきます。

議論の末、すでに決まっている事柄を再考したくないというのは尊敬の念です。 しかし、＃35950、 Redditスレッド、そしてここで行われた議論を検討した後、彼らが//go:embedを使用する決定を正当化するとは思わない。

埋め込むファイルを示すための構文に触れたコメントは次のとおりです。

• https://github.com/golang/go/issues/35950#issuecomment -561443566 " //go:embedアプローチは、別のレベルの複雑さももたらします。タイプチェックを行うには、魔法のコメントを解析する必要があります。コード。「埋め込みパッケージ」アプローチは、静的分析に適しているようです。」 （注：改訂された//go:embed提案では、チェックコードの入力が簡単になりますが、アナライザーが実際に使用されている文字列を確認したい場合は、go / astにないため、簡単ではありません。）
• https://github.com/golang/go/issues/35950#issuecomment -561450136 "これは、パッケージを使用するための非常に強力な議論です。また、通常のgodocですべてを文書化できるため、より読みやすく、文書化可能になります。 cmd / goのドキュメントの奥深くよりも。」 （注：パッケージの埋め込みタイプは簡単な参照ポイントを提供するため、これは主に＃43217で対処されていると思います。）
• https://github.com/golang/go/issues/35950#issuecomment -561840094 "go build / linkの一部にできない理由はありgo build -embed example=./path/example.txtと公開するパッケージアクセス（例： embed.File("example")を使用する代わりにgo:embed ？ "（ //go:ディレクティブを超える関数構文を提案します。反対票を投じましたが、 go build提案したので疑わしいですフラグ。）
• https://github.com/golang/go/issues/35950#issuecomment -561726107 "私はコードにコンパイルされるコメントのファンではありませんが、コンパイルに影響を与える疑似パッケージも少しあると思いますディレクトリアプローチを使用しない場合は、実際に言語に組み込まれたトップレベルの宣言を含める方が少し理にかなっているかもしれません。インポートと同様に機能しますが、ローカルパスと割り当てるには名前が必要です。」 （ //go:や新しい組み込み関数は好きではありませんが、コメントよりもコードを好みます。）
• https://github.com/golang/go/issues/35950#issuecomment -561856033 "また、 //go:generateディレクティブはgoビルドで自動的に実行されないため、goビルドの動作は少し一貫していないように見える場合があります： //go:embedは自動的に機能しますが、 //go:generate場合は、手動でgo generateを実行する必要があります（ //go:generateは、ビルドに必要な.goファイルを生成する場合、すでにgo getフローを中断できます）。 「」 （完全を期すために含まれていますが、我々はすでに持っている//go:行い、影響はありません両方というディレクティブをgo buildさえせずに行動を//go:embed私はこの引数が魅力的な見つけることはありませんので、。）
• https://github.com/golang/go/issues/35950#issuecomment -562005821 "ディレクティブではなく、新しいパッケージに投票します。把握しやすく、扱いやすく、管理しやすく、はるかに簡単です。たとえば、「go：generate」などのGoディレクティブのドキュメントを簡単に見つけることができますか？「fmt」パッケージのドキュメントはどうですか？これでどこに行くのかわかりますか？」 （繰り返しますが、主に＃43217で対処されています。）
• https://github.com/golang/go/issues/35950#issuecomment -562200553 "特別なディレクトリ名（static /）ではなくコメントプラグマ（// go：embed）を支持する1つの引数：コメントでパッケージ（またはxtestアーカイブ）のテストアーカイブにファイルを埋め込みますが、テスト対象のライブラリには埋め込みません。コメントは_test.goファイルに表示する必要があります。」 （注：引数は特別なディレクトリに対するものであり、特に//go:embedに対するものではありません。同じ引数は、 embed.Files関数などにも適用されます。）
• https://github.com/golang/go/issues/35950#issuecomment -562235108「Go構文を使用するためのpackage embedアプローチが好きです」
• https://github.com/golang/go/issues/35950#issuecomment-562713786「$＃$ import "C"アプローチはすでに「魔法の」インポートパスの前例を作っています。IMOはかなりうまくいきました。」
• https://github.com/golang/go/issues/35950#issuecomment -562768318「魔法のコメントのような別のシグナルを必要とする代わりに、埋め込みファイルを読み取るためのAPIを自動的に提供することについて多くの人が話しました。アプローチに馴染みのあるプログラム的な構文を提供するので、進むべき道です。前述のように、おそらくruntime/embed特別なパッケージを選択すれば、それを満足させ、将来的に簡単に拡張できるようになります。」
• https://github.com/golang/go/issues/35950#issuecomment -562959330 "コメントを再利用する代わりに（コメントはあちこちに散らばってしまい、個人的なメモでは、ただひどく感じます）、[... ]。」 （埋め込みファイルを列挙するためにgo.modファイルを使用することを提案し続けます。公平を期すために、「これは、文字列リテラルのみを引数として許可するようにマジックパッケージを制限する必要があるなどの問題を回避しますが、チェックするのが難しいことを意味します埋め込まれたアセットは実際にはどこでも使用されるか、最終的には自重になります。」）
• https://github.com/golang/go/issues/35950#issuecomment -562966654 "さらに別のアイデア：go.modに埋め込まれた新しい種類の動詞を追加する代わりに、新しい種類のパッケージであるデータパッケージを導入できます。 、通常の方法でgo.modにインポートされ、使用されます。これがストローマンのスケッチです。」 （コメントよりもコードを優先します。）
• https://github.com/golang/go/issues/35950#issuecomment -563156010 "これはまだ言及されていないものです：Goソース処理ツール（コンパイラー、静的アナライザー）のAPIはランタイムAPIと同じくらい重要です。この種のAPIは、エコシステムの成長に役立つGoのコアバリューです（ go/ast / go/formatやgo mod edit ）。[...]の場合特別なパッケージです。 go.mod解析（ go modツール）またはgo/astパーサーで変更するものは何もありません。」
• https://github.com/golang/go/issues/35950#issuecomment -601748774go.resリソースファイルのリストを提案します。 コメントではなくコードを使用します。
• https://old.reddit.com/r/golang/comments/hv96ny/qa_goembed_draft_design/fyv9gxw/ "なぜ// go：embedコメントが必要なのですか。たとえばbincludeはファイル/ディレクトリを含めるためにbinclude.Include(filename)を実行します。約fs.Embed(filename) ？」
• https://github.com/golang/go/issues/41191#issuecomment -686625127「私の意見では、このツールの変更をサポートするために言語に糖衣構文を追加することは言語の変更です。これは他の人にも明らかだと確信しています。しかし、これは事実上コードとしてのコメントです。魔法/砂糖は言語の単純さと読みやすさを損なうと強く感じています。ファイルを埋め込む魔法のコメントを見逃しがちです。」
• https://github.com/golang/go/issues/41191#issuecomment -690423900 "@tristanfisherと同様の懸念があります。Goは長い間（最初から？）コンパイラ指令としてマジックコメントを使用してきましたが、はコーナーケース向けであり、コードに表示されることはめったにありません。静的コンテンツをGoバイナリに埋め込むことが一般的であることを考えると、 //go:embed方が一般的である可能性があります。コンパイラの別の構文を検討するときが来たのかもしれません。ディレクティブ？」
• https://github.com/golang/go/issues/41191#issuecomment-690522509 「魔法のコメントについての懸念を共有します。」

コメントを読んでいると、ツールを壊すような変更を避けたいという警告とともに、常にGo構文を支持しているように見えます。 //go:embedをつづりとして主張している人は誰もいません//go:embedが、そのまま受け入れるだけでした。 レガシータイプチェッカーの下位互換性スタブを備えた新しいコンパイラ組み込み関数を追加することは、 //go:ディレクティブよりも、ディスカッション参加者の表明された好みに沿っているように見えます。

＃43216と＃43217の「いいね」/「いいね」の投票のスタイルでは、次のようになります。

• 新しいコンパイラ組み込み関数（ CL 276835など）を好む場合は、

  import "embed"
  
  var website = embed.Files("logo.jpg", "static/*")
  

  その他の使用例については、 embed_test.goを参照してください。

  （注：引数は、単なる文字列値ではなく、文字列リテラルである必要があります。つまり、 const logo = "logo.jpg"ような宣言された文字列定数、または"logo" + ".jpg"ような定数文字列式も許可されません。ただし、 embed.Filesなどは、変数を初期化するだけでなく、どのような状況でも使用できます。）

• 新しいコンパイラ指令（つまり、現在の提案）を好む場合は、親指を下ろしてください（👎）：

  import "embed"
  
  //go:embed logo.jpg static/*
  var website embed.FS
  

@mdempskyラスは非常に明確だったように感じます。彼に対する決定の取り消しを正当化するために何が必要か、新しい情報です。 以前のコメントを集めることは明らかにそうではないと思います。 攻撃は意図されていません。

これらの新しい種類の機能の前例はありませんよね？ つまり、通常のパッケージ関数のように見えますが、実際には特定の方法でのみ呼び出すことができる特別な種類の組み込み関数ですか？

「組み込み」と言いますが、現在の組み込みは通常のGo関数とまったく同じように動作します。

x := 10000
_ = bits.RotateLeft64(10, x)

Go関数のように見えるが、Go関数とは異なる（より制限的な）構文を持つように新しいディレクティブをドレスアップすることは、私が座っているところからは貧弱なオプションのように思えます。 //go:ディレクティブとは異なり、 embedを仕様に記述する必要があると思います。

（エクスポートされていないtype internalString string引数を取る関数を作成することで、通常のGoコードで「許可されるリテラル引数のみ」を概算できますが、CLが変更を行うため、提案しているものではないことがわかります。パーサーとタイプチェッカー。）

@Merovius Go提案プロセスによると：

コンセンサスと不一致

提案プロセスの目標は、結果についてタイムリーに一般的なコンセンサスに達することです。

一般的なコンセンサスに達することができない場合、提案レビューグループは、問題をレビューして議論し、彼らの間でコンセンサスに達することによって次のステップを決定します。 提案レビューグループ間でさえ合意に達することができない場合（これは非常に珍しいことです）、アービター（rsc @）はディスカッションをレビューし、次のステップを決定します。

私のコメントを読んだところ、コンセンサスはGoコード構文を支持しているようでした。 現在のコンセンサスが実際に//go:embedに固執することである場合、私はそれを尊重します。 しかし、文書化されたプロセスが//go:embed前進するという最初の決定を正当化したとは思いません。

（現時点では、投票結果は新しいディレクティブよりも新しい関数を弱く支持していますが、それほど多くはありません。親指を上に向けても、親指を下に向けて少なくとも2：1を上回らない場合は、これを削除するだけで問題ありません。）

@cespare

これらの新しい種類の機能の前例はありませんよね？ つまり、通常のパッケージ関数のように見えますが、実際には特定の方法でのみ呼び出すことができる特別な種類の組み込み関数ですか？

ユニバースの事前に宣言された関数とパッケージの安全でない関数の両方があります。

安全でないパッケージはGo仕様に文書化されていると主張できますが、そうである必要はないと私は主張します。 Goは、ユーザーがパッケージunsafeを利用できないモードをサポートするために使用されていました。現在でも、package unsafeには、Go仕様ではなく、パッケージドキュメントにのみ記載されている機能と制限があります。

Goランタイム内には、Goコンパイラーによってのみ実装される内部関数もあります。 例： getg 、 getcallerpc 、 getcallersp 、およびgetclosureptr 。

（エクスポートされない型のinternalString文字列引数を受け取る関数を作成することにより、通常のGoコードで「許可されるリテラル引数のみ」を概算できます。

これは、レガシータイプチェッカーの動作をさらに絞り込むための合理的な追加になると思います。

しかし、CLがパーサーとタイプチェッカーに変更を加えるため、それはあなたが提案しているものではないことを私は収集します。）

CL 276835は、 //go:embed追加された新しいパーサーコードを削除することを除いて、パーサーを変更しません。 タイプチェッカーは変更されますが、以前の//go:embed同等です。

パッケージの埋め込みを認識するようにgo / typesを拡張するのは簡単ですが、CL 276835がまだ機能することを示すために、特にそうしないことを選択しました（たとえば、cmd / vetはパッケージの埋め込みの単体テストで失敗しません）。

@mdempskyその時点でコンセンサスが得られたかどうかについて意見がその決定に当てはまります。

すべての人を満足させる必要があるのは、決定とそれが行われたプロセスの両方に関して、DDoSベクトルです。

FTR、ツールと言語の変更に関する質問が議論され、「文字列リテラルと文字列定数」の間のトレードオフきました。

すべての人を満足させる必要があるのは、決定とそれが行われたプロセスの両方に関して、DDoSベクトルです。

私は個人的に満足することを要求していません、そしてあなたが私の投稿をそのように特徴づけているのは侮辱的だと思います。 以前、私がGo言語やGoコンパイラに精通していないかのように私に話しかけました。 叱責でやめてください。

私は、ほぼ普遍的に人々が新しい//go:ディレクティブを追加しないことを好むと表明した多くのコメントを上にコミュニティの圧倒的な表現された好みは、Go構文を好むように私には見えました、そして私のコメントは彼らの述べられた好みを擁護することを主張していました。

ただし、現状では、 https： //github.com/golang/go/issues/41191#issuecomment-747095807には親指を立てるよりも親指を下げる方が多くあり//go:embedをサポートできるようになりました。それが実際にはコミュニティの好みであり、提案者の好みだけではないことを確認します。 あなたが意図しているように、議論が打ち切られていたら、この結果は達成されなかったでしょう。

FTR、ツールと言語の変更に関する質問が議論され、「文字列リテラルと文字列定数」の間のトレードオフ

そのコメントは私が行っていた議論とは無関係です。 CL 276835でプロトタイプを作成した代替スペルは、既存の//go:embedスペルとまったく同じ技術的特性を持っています。どのファイルを埋め込むかを知る必要があるツールは、Goソースファイルを異なる方法で処理するために更新する必要があります（エラーなど）。 //go:embedコメントまたはembed.Bytes組み込み関数の誤用について）、既存のツールはそれらを心配することなくコードを合理的に処理し続けることができます（たとえば、go / typesは//go:embedコメントを無視します）ただし、誤った変数タイプに適用されているかどうかは検出されず、スタブ宣言を使用してembed.Bytesタイプチェックはできますが、文字列リテラル以外の引数を使用するすべての呼び出しを拒否することはできません）。

これらのいずれかが「言語の変化」であるかどうかの問題は、技術的というよりも哲学的です。

（ //go:embed提案の下での「プログラムが有効かどうかは変わらない」というRussの主張も正しくありません。https：//github.com/golang/go/issues/41191#issuecomment-747799509に例を示します。 Go仕様に従って有効であり、Go 1.15までのGoツールチェーンリリースでも受け入れられていたパッケージですが、Go 1.16では無効になります。）

var website = embed.Files("logo.jpg", "static/*")を使用するというマットの提案に👍を与えた人として、コメントフォーム（ //go:embed logo.jpg static/* ）を使用することに関する私の懸念は「使いやすさ」です。

たとえば、これら2つのプログラムサンプルは、「インポート」が失敗したという理由だけで、2つの異なるものを出力します。

import (
    "fmt"
)

//go:embed sample.txt
var sample string

func main() {
    fmt.Println(sample) // will print a blank line
}

import (
    "embed"
    "fmt"
)

//go:embed sample.txt
var sample string

func main() {
    fmt.Println(sample) // will print contents of sample.txt
}

開発者に言語セマンティクスによるインポートの使用を強制することにより、埋め込みファイルが期待どおりに初期化されないために期待どおりに機能しない問題を最小限に抑えることができます。

@ kushieda-minori私の提案も使いやすいと思いますが

./x.go:7:3: //go:embed only allowed in Go files that import "embed"

とにかくタイプembed.Bytesとembed.String変数を宣言するには「埋め込み」をインポートする必要があるため、この問題は＃43217によってさらに軽減されると思います。 また、 //go:embedディレクティブを誤った型の変数に適用すると、コンパイラー（go / typesまたはcmd / vetは除く）もすでにエラーを報告します。

ただし、 @ mdempskyは、古いバージョンのGoで誤ってコンパイルしても失敗せず、埋め込みが機能したという誤った感覚を与える可能性があります。

古いバージョンのGoにはパッケージが埋め込まれていないため、 import "embed"は失敗します。 ユーザーが次のように書くことができるリスクがあるのは事実です。

package p

//go:embed foo.txt
var foo []byte

Go1.15以前では黙って受け入れられます。 ただし、Go1.16以降では受け入れられません。 少なくとも、Go1.15とGo1.16の両方でコンパイルされ、セマンティクスが異なるプログラムはありません（少なくともパッケージが埋め込まれているため）。

ここでの適切な（部分的な）修正は、cmd / compileが不明な//go:ディレクティブの受け入れを停止することだと思います。 たとえば、Go組み込み構文に関連する現在の提案の別の制限は、 //go:embedディレクティブを誤って入力した場合（たとえば、 //go:enbed 、 //go;embed 、または// go:embedスペース付き）、それも黙って無視されます。 （ enbed.Bytes("foo.txt")ようなタイプミスは、変更されていないgo / typesでも、タイプチェックエラーを引き起こします。）

検証されていないgo:ディレクティブの優れた点。 それが実施された場合、タイプミスを見つけるのが難しいことを軽減するのに役立ちます。

私が今持っていたもう1つの考えは、必要に応じてインポートを自動的に追加/削除するようにツールが設定されていることです。 ツールが古くなっている場合、「未使用」のembedインポートを削除しないようにする必要がありますか？ embed.Stringなどを使用すれば解決することに気づきましたが、通常の[]byte]とstringを使用すると完全に有効になるはずです。 これは、特定のembed.*エイリアスが表示されない場合に、何かを機能させるためにWebスニペットをチェリーピッキングしている新しいgopherにとってイライラする可能性があります。

ただし、通常の[]byte]とstringは完全に有効であると想定されています。

＃43217が受け入れられた場合はそうではありません。 ＃43216と＃43217を読むことをお勧めします。 どちらもこれまでのところ圧倒的に前向きな支持を受けており、私には受け入れられる可能性が非常に高いようです。 （私は提案審査委員会には参加していません。）

おかげさまで、＃43217を初めて読んだとき、キーワードを逃しました
embed.*タイプを使用するための「持っている」。

その時残っている私の唯一の懸念はあなたが指摘した最後のものだと思います。

木、2020年12月17日には、午前20時24分マシューDempsky [email protected]
書きました：

ただし、通常の[] byte]と文字列の使用は完全に有効であると想定されています。

＃43217 https://github.com/golang/go/issues/43217が
受け入れられました。 ＃43216を読むことをお勧めします
https://github.com/golang/go/issues/43216および＃43217
https://github.com/golang/go/issues/43217 。 彼らは両方とも受け取った
これまでのところ圧倒的に前向きなサポートであり、受け入れられる可能性が非常に高いようです
私に。 （私は提案審査委員会には参加していません。）

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/41191#issuecomment-747808153 、または
退会
https://github.com/notifications/unsubscribe-auth/ADLZABJWBJX475BVYDVD6ODSVKVOTANCNFSM4QTHVTUA
。