Go: proposition : cmd/go : prise en charge de l'intégration d'éléments statiques (fichiers) dans des fichiers binaires

Cela vaut la peine de se demander si embedglob doit prendre en charge une arborescence de fichiers complète, peut-être en utilisant la syntaxe ** prise en charge par certains shells Unix.

Certaines personnes auraient besoin de pouvoir servir les ressources intégrées avec HTTP en utilisant le http.FileServer .

Personnellement, j'utilise soit mjibson/esc (qui fait cela) soit, dans certains cas, ma propre implémentation d'intégration de fichiers qui renomme les fichiers pour créer des chemins uniques et ajoute une carte des chemins d'origine aux nouveaux, par exemple "/js/bootstrap.min.js": "/js/bootstrap.min.827ccb0eea8a706c4c34a16891f84e7b.js" . Ensuite, vous pouvez utiliser cette carte dans les modèles comme ceci : href="{{ static_path "/css/bootstrap.min.css" }}" .

Je pense qu'une conséquence de cela serait qu'il ne serait pas trivial de déterminer quels fichiers sont nécessaires pour construire un programme.

L'approche //go:embed introduit également un autre niveau de complexité. Vous auriez à analyser les commentaires magiques pour même taper le code. L'approche « embed package » semble plus conviviale pour l'analyse statique.

(Je réfléchis juste à voix haute ici.)

@opennota ,

aurait besoin de la capacité de servir les actifs intégrés avec HTTP en utilisant le http.FileServer .

Oui, le premier lien ci-dessus est un package que j'ai écrit ( en 2011, avant Go 1 ) et que j'utilise toujours, et il prend en charge l'utilisation de http.FileServer : https://godoc.org/perkeep.org/pkg/fileembed#Files.Open

@cespare ,

L'approche //go:embed introduit également un autre niveau de complexité. Vous auriez à analyser les commentaires magiques pour même taper le code. L'approche « embed package » semble plus conviviale pour l'analyse statique.

Oui, bonne remarque. C'est un argument très fort pour l'utilisation d'un package. Cela le rend également plus lisible et documentable, car nous pouvons tout documenter avec godoc ordinaire, plutôt qu'en profondeur dans les documents de cmd/go.

@bradfitz - Voulez-vous fermer ce https://github.com/golang/go/issues/3035 ?

@agnivade , merci d'avoir trouvé ça ! Je pensais m'en souvenir mais je ne l'ai pas trouvé. Laissons-le ouvert pour le moment et voyons ce que les autres en pensent.

Si nous utilisons le package magique, nous pourrions utiliser l'astuce du type non exporté pour nous assurer que les appelants transmettent les constantes de compilation en tant qu'arguments : https://play.golang.org/p/RtHlKjhXcda.

(Il s'agit de la stratégie référencée ici : https://groups.google.com/forum/#!topic/golang-nuts/RDA9Hag8RZw/discussion)

Une préoccupation que j'ai est de savoir comment gérer les ressources individuelles ou tous les actifs trop volumineux pour tenir dans la mémoire et s'il y aurait peut-être une étiquette de construction ou une option d'accès par fichier pour choisir entre la prise en charge du temps d'accès par rapport à l'empreinte mémoire ou une implémentation intermédiaire.

la façon dont j'ai résolu ce problème (parce que bien sûr j'ai aussi ma propre implémentation :) ) est de fournir une implémentation http.FileSystem qui sert tous les actifs intégrés. De cette façon, vous ne comptez pas sur des commentaires magiques pour apaiser le vérificateur de types, les actifs peuvent facilement être servis par http, une implémentation de secours peut être fournie à des fins de développement (http.Dir) sans changer le code, et la version finale L'implémentation est assez polyvalente, car http.FileSystem couvre pas mal de choses, non seulement dans la lecture de fichiers, mais aussi dans la liste des répertoires.

On peut toujours utiliser des commentaires magiques ou autre pour spécifier ce qui doit être intégré, bien qu'il soit probablement plus facile de spécifier tous les globs via un fichier texte brut.

@AlexRouSg Cette proposition ne concernerait que les fichiers qu'il convient d'inclure directement dans l'exécutable final. Il ne serait pas approprié de l'utiliser pour des fichiers trop volumineux pour tenir en mémoire. Il n'y a aucune raison de compliquer cet outil pour gérer ce cas ; dans ce cas, n'utilisez pas cet outil.

@ianlancetaylor , je pense que la distinction que @AlexRouSg faisait était entre avoir les fichiers fournis en tant que []byte s globaux (mémoire non paginable, potentiellement inscriptible) et fournir une vue en lecture seule et à la demande d'une section ELF qui peut normalement en direct sur le disque (dans l'exécutable), comme via un appel Open qui renvoie un *io.SectionReader . (Je ne veux pas intégrer http.File ou http.FileSystem dans cmd/go ou runtime... net/http peut fournir un adaptateur.)

@bradfitz à la fois http.File lui-même est une interface sans dépendances techniques avec le package http . Il peut être judicieux pour toute méthode Open de fournir une implémentation conforme à cette interface, car les méthodes Stat et Readdir sont toutes deux très utiles pour de tels actifs

@urandom , il ne pouvait cependant pas implémenter http.FileSystem sans faire référence au nom "http.File" (https://play.golang.org/p/-r3KjG1Gp-8).

@robpike et moi avons discuté d'une proposition pour faire cela il y a des années (avant qu'il n'y ait un processus de proposition) et nous n'avons jamais recommencé à faire quoi que ce soit. Ça me dérange depuis des années que nous n'ayons jamais fini de faire ça. L'idée, si je me souviens bien, était d'avoir simplement un nom de répertoire spécial comme "static" contenant les données statiques et de les rendre automatiquement disponibles via une API, sans annotations nécessaires.

Je ne suis pas convaincu de la complexité d'un bouton "compressé vs pas". Si nous faisons cela, les gens voudront que nous ajoutions un contrôle sur la compression, le niveau de compression, etc. Tout ce que nous devrions ajouter, c'est la possibilité d'intégrer un fichier d'octets bruts. Si les utilisateurs souhaitent stocker des données compressées dans ce fichier, tant mieux, les détails leur appartiennent et aucune API n'est nécessaire du côté de Go.

Quelques réflexions :

• Il ne devrait pas être possible d'intégrer un fichier en dehors du module effectuant l'intégration. Nous devons nous assurer que les fichiers font partie des fichiers zip du module lorsque nous les créons, ce qui signifie également qu'il n'y a pas de liens symboliques, de conflits de casse, etc. Nous ne pouvons pas modifier l'algorithme qui produit les fichiers zip sans casser les sommes.
• Je pense qu'il est plus simple de restreindre l'intégration dans le même répertoire (si des commentaires //go:embed sont utilisés) ou dans un sous-répertoire spécifique (si static est utilisé). Cela facilite grandement la compréhension de la relation entre les packages et les fichiers intégrés.

Dans tous les cas, cela bloque l'intégration de /etc/shadow ou .git . Ni l'un ni l'autre ne peut être inclus dans un module zip.

En général, je crains d'étendre trop la portée de la commande go. Cependant, le fait qu'il existe tant de solutions à ce problème signifie qu'il devrait probablement y avoir une solution officielle.

Je connais go_embed_data et go-bindata (dont il existe plusieurs forks), et cela semble couvrir ces cas d'utilisation. Y a-t-il des problèmes importants que les autres résolvent que cela ne couvre pas ?

Le blocage de certains fichiers ne devrait pas être trop difficile, surtout si vous utilisez un répertoire static ou embed . Les liens symboliques peuvent compliquer un peu cela, mais vous pouvez simplement l'empêcher d'intégrer quoi que ce soit en dehors du module actuel ou, si vous êtes sur GOPATH, en dehors du package contenant le répertoire.

Je ne suis pas particulièrement fan d'un commentaire qui compile en code, mais je trouve également un peu étrange le pseudo-paquet qui affecte la compilation. Si l'approche par répertoire n'est pas utilisée, il serait peut-être plus logique d'avoir une sorte embed déclaration de niveau supérieur import , mais ne prendrait en charge que les chemins locaux et nécessiterait un nom pour lui être attribué. Par exemple,

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))
}

Edit : Tu m'as devancé, @jayconrod.

Pour développer sur https://github.com/golang/go/issues/35950#issuecomment -561703346, il y a un casse-tête sur l'API exposée. Les moyens évidents d'exposer les données sont les interfaces []byte , string et Read -ish.

Le cas typique est que vous voulez que les données intégrées soient immuables. Cependant, toutes les interfaces exposant []byte (ce qui inclut io.Reader , io.SectionReader , etc.) doivent soit (1) faire une copie, (2) autoriser la mutabilité, ou (3) être immuable en dépit d'être un []byte . Exposer les données en tant que string s résout ce problème, mais au prix d'une API qui finira souvent par nécessiter une copie de toute façon, car beaucoup de code qui consomme des fichiers intégrés nécessite finalement des tranches d'octets d'une manière ou d'une autre.

Je suggérerais l'itinéraire (3) : être immuable malgré le fait qu'il s'agisse d'un []byte . Vous pouvez appliquer cela à moindre coût en utilisant un symbole en lecture seule pour le tableau de sauvegarde. Cela vous permet également d'exposer en toute sécurité les mêmes données qu'un []byte et un string ; les tentatives de mutation des données échoueront. Le compilateur ne peut pas profiter de l'immuabilité, mais ce n'est pas une trop grande perte. C'est quelque chose que la prise en charge de la chaîne d'outils peut apporter à la table que (pour autant que je sache) aucun des packages codegen existants ne le fait.

(Un package de codegen tiers pourrait le faire en générant un fichier d'assemblage générique contenant des symboles DATA qui sont marqués comme en lecture seule, puis de courts fichiers d'assemblage spécifiques à l'arch exposant ces symboles sous la forme de string s et []byte s. J'ai écrit CL 163747 spécifiquement avec ce cas d'utilisation à l'esprit, mais je n'ai jamais réussi à l'intégrer dans des packages codegen.)

Je ne sais pas de quoi vous parlez en termes d'immuabilité. io.Reader applique déjà l'immuabilité. C'est tout l'intérêt. Lorsque vous appelez Read(buf) , il copie les données dans le tampon que _vous_ avez fourni. Changer buf après cela n'a aucun effet sur les composants internes du io.Reader .

Je suis d'accord avec @DeedleFake. Je ne veux pas jouer à des jeux avec des supports de tableau magiques []byte . Vous pouvez copier du binaire dans les tampons fournis par l'utilisateur.

Juste une autre ride ici - j'ai un projet différent qui utilise le code source DTrace (intégré). Ceci est sensible aux différences entre \n et \r\n. (Nous pouvons discuter si c'est une chose stupide dans DTrace ou non - c'est hors de propos et c'est la situation aujourd'hui.)

Il est très utile que les chaînes backticked traitent les deux comme \n quelle que soit la façon dont elles apparaissent dans la source, et je m'appuie sur cela avec un go-generate pour intégrer le DTrace.

Donc, s'il y a un fichier d'intégration ajouté à la commande go, je suggérerais doucement que les options pour modifier la gestion de CR/CRLF pourraient être très utiles, en particulier pour les personnes qui pourraient développer sur différents systèmes où les fins de ligne par défaut peuvent être un piège.

Comme avec la compression, j'aimerais vraiment m'arrêter à "copier les octets du fichier dans le binaire". Normalisation CR/CRLF, normalisation Unicode, gofmt'ing, tout ce qui appartient à l'autre. Archivez les fichiers contenant les octets exacts que vous souhaitez. (Si votre contrôle de version ne peut pas les laisser seuls, vérifiez peut-être le contenu gzippé et compressez-le au moment de l'exécution.) Il existe _beaucoup_ de boutons de gestion de fichiers que nous pourrions imaginer ajouter. Arrêtons-nous à 0.

Il est peut-être trop tard pour introduire un nouveau nom de répertoire réservé, autant que je le souhaite.
(Il n'était pas trop tard en 2014, mais il est probablement trop tard maintenant.)
Ainsi, une sorte de commentaire d'opt-in peut être nécessaire.

Supposons que nous définissions un type runtime.Files. Alors vous pourriez imaginer écrire :

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

Et puis, au moment de l'exécution, vous appelez simplement files.Open pour récupérer un interface { io.ReadSeeker; io.ReaderAt } avec les données. Notez que la var n'est pas exportée, de sorte qu'un package ne peut pas parcourir les fichiers intégrés d'un autre package.

Noms à déterminer mais en ce qui concerne le mécanisme, il semble que cela devrait suffire, et je ne vois pas comment faire plus simple. (Simplifications bienvenues bien sûr !)

Quoi que nous fassions, il doit être possible de soutenir avec Bazel et Gazelle aussi. Cela signifierait que Gazelle reconnaisse le commentaire et écrive une règle Bazel indiquant les globs, puis nous aurions besoin d'exposer un outil (go tool embedgen ou autre) pour générer le fichier supplémentaire à inclure dans la construction (la commande go le faire automatiquement et ne jamais afficher le fichier supplémentaire). Cela semble assez simple.

Si divers munging ne font pas l'affaire, alors c'est un argument contre l'utilisation de cette nouvelle fonctionnalité. Ce n'est pas un frein pour moi - je peux utiliser go generate comme je l'ai fait, mais cela signifie que je ne peux pas bénéficier de la nouvelle fonctionnalité.

En ce qui concerne le munging en général - je peux imaginer une solution où quelqu'un fournit une implémentation d'une interface (quelque chose comme un Reader() d'un côté, et quelque chose pour recevoir le fichier de l'autre - peut-être instancié avec un io.Reader à partir du fichier lui-même) -- que le cmd go créerait et exécuterait pour préfiltrer le fichier avant de l'intégrer. Ensuite, les gens peuvent fournir le filtre qu'ils veulent. J'imagine que certaines personnes fourniraient des filtres quasi standard comme une implémentation dos2unix, une compression, etc. (Peut-être qu'ils devraient même être chaînables.)

Je suppose qu'il faudrait supposer que quel que soit le processeur intégré, il doit être compilable sur ~ chaque système de construction, car cela créerait un outil natif temporaire à cette fin.

Il est peut-être trop tard pour introduire un nouveau nom de répertoire réservé, autant que je le souhaite. [...] sorte de commentaire d'opt-in peut être nécessaire.

Si les fichiers ne sont accessibles que via un package spécial, disons runtime/embed , alors l'importation de ce package pourrait être le signal d'activation.

L'approche io.Read semble pouvoir ajouter une surcharge importante (en termes de copie et d'empreinte mémoire) pour des opérations linéaires conceptuellement simples comme strings.Contains (comme dans cmd/go/internal/cfg ) ou , critique, template.Parse .

Pour ces cas d'utilisation, il semble idéal de permettre à l'appelant de choisir de traiter le blob entier comme un string (probablement mappé en mémoire) ou un io.ReaderAt .

Cela semble cependant compatible avec l'approche générale de runtime.Files : la chose renvoyée par runtime.Files.Open pourrait avoir une méthode ReadString() string qui renvoie la représentation mappée en mémoire.

une sorte de commentaire d'opt-in peut être nécessaire.

Nous pourrions le faire avec la version go dans le fichier go.mod . Avant 1.15 (ou autre) le sous-répertoire static contiendrait un package, et à 1.15 ou plus, il contiendrait des actifs intégrés.

(Cependant, cela n'aide pas vraiment en mode GOPATH .)

Je ne suis pas convaincu de la complexité d'un bouton "compressé vs pas". Si nous faisons cela, les gens voudront que nous ajoutions un contrôle sur la compression, le niveau de compression, etc. Tout ce que nous devrions ajouter, c'est la possibilité d'intégrer un fichier d'octets bruts.

Bien que j'apprécie la recherche de simplicité, nous devons également nous assurer que nous répondons aux besoins des utilisateurs.

12 des 14 outils répertoriés sur https://tech.townsourced.com/post/embedding-static-files-in-go/#comparison prennent en charge la compression, ce qui suggère qu'il s'agit d'une exigence assez courante.

Il est vrai que l'on pourrait faire la compression en tant qu'étape de pré-construction à l'extérieur, mais cela nécessiterait toujours 1) un outil pour faire la compression 2) vérifier une sorte de blob assets.zip dans vcs 3) probablement un utilitaire bibliothèque autour de l'API intégrée pour annuler la compression. À ce stade, on ne sait pas du tout quel est l'avantage.

Trois des objectifs énumérés dans la proposition initiale étaient les suivants :

• ne pas archiver les fichiers générés
• make go install / go build fait l'intégration automatiquement
• stocker les actifs compressés dans le binaire, le cas échéant

Si nous lisons le second comme « ne nécessite pas d'outil distinct pour l'intégration », alors la non prise en charge directe ou indirecte des fichiers compressés ne permet pas d'atteindre ces trois objectifs.

Cela doit-il être au niveau du package ? Le niveau du module semble une meilleure granularité puisque très probablement un module = un projet.

Étant donné que ce répertoire ne contiendrait pas de code Go, cela pourrait-il être quelque chose comme _static ?

† ou, si c'est le cas, il serait traité comme des octets arbitraires dont le nom se termine par ".go" au lieu de code Go à compiler

S'il s'agit d'un répertoire spécial, la logique pourrait simplement consister à aspirer tout et n'importe quoi dans cette arborescence de répertoires. Le package d'intégration magique pourrait vous permettre de faire quelque chose comme embed.Open("img/logo.svg") pour ouvrir un fichier dans un sous-répertoire de l'arborescence des ressources.

Les cordes semblent assez bonnes. Ils peuvent facilement être copiés dans []byte ou convertis en Reader . La génération de code ou les bibliothèques pourraient être utilisées pour fournir des API plus sophistiquées et gérer les choses pendant init . Cela pourrait inclure une décompression ou la création d'un http.FileSystem .

Windows n'a-t-il pas un format spécial pour l'intégration des actifs. Cela devrait-il être utilisé lors de la création d'un exécutable Windows ? Si oui, cela a-t-il des implications sur les types d'opérations qui peuvent être fournis?

N'oubliez pas les gitfs

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

Y a-t-il une raison pour laquelle cela ne pourrait pas faire partie de go build / link ... par exemple go build -embed example=./path/example.txt et un package qui expose l'accès (par exemple embed.File("example") , au lieu d'utiliser go:embed ?

vous avez besoin d'un talon pour cela dans votre code cependant

@egonelbre le problème avec go build -embed est que tous les utilisateurs auraient besoin de l'utiliser correctement. Cela doit être entièrement transparent et automatique ; Les commandes go install ou go get existantes ne peuvent pas arrêter de faire la bonne chose.

@bradfitz Je recommanderais https://github.com/markbates/pkger sur Packr. Il utilise l'API de bibliothèque standard pour travailler avec des fichiers.

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
}

Ou peut-être que certaines balises ou drapeaux de construction pourraient le faire revenir à faire des choses au moment de l'exécution à la place. Perkeep (lié ci-dessus) a un tel mode, ce qui est bien pour accélérer le développement incrémentiel où vous ne vous souciez pas de lier un gros binaire.

mjibson/esc le fait également, et c'est une grande amélioration de la qualité de vie lors du développement d'une application Web ; non seulement vous économisez du temps de liaison mais évitez également d'avoir à redémarrer l'application, ce qui peut prendre un temps considérable et/ou nécessiter la répétition d'étapes supplémentaires pour tester vos modifications, selon l'implémentation de la webapp.

Problèmes avec la situation actuelle :

• L'utilisation d'une solution basée sur go:generate gonfle l'historique de git avec une deuxième copie (et légèrement plus grande) de chaque fichier.

Buts:

• ne pas archiver les fichiers générés

Eh bien, cette partie est facilement résolvable en ajoutant simplement les fichiers générés au fichier .gitignore ou équivalent. J'ai toujours fait ça...

Ainsi, Go pourrait simplement avoir son propre outil d'intégration "officiel" qui s'exécute par défaut sur go build et demander aux gens d'ignorer ces fichiers par convention. Ce serait la solution la moins magique disponible (et rétrocompatible avec les versions Go existantes).

Je suis juste en train de réfléchir/réfléchir à haute voix ici... mais j'aime en fait l'idée proposée dans l'ensemble. ??

De plus, étant donné que les directives //go:generate ne s'exécutent pas automatiquement sur go build le comportement de go build peut sembler un peu incohérent : //go:embed fonctionnera automatiquement mais pour //go:generate vous devez exécuter go generate manuellement. ( //go:generate peut déjà casser le flux go get s'il génère les fichiers .go nécessaires à la construction).

//go:generate peut déjà casser le flux de go get s'il génère les fichiers .go nécessaires à la construction

Je pense que le flux habituel pour cela, et celui que j'ai généralement utilisé, bien qu'il ait fallu un peu de temps pour s'y habituer, consiste à utiliser go generate entièrement comme un outil de développement et à simplement valider les fichiers qui il génère.

@bradfitz, il n'a pas besoin d'implémenter http.FileSystem lui-même. Si l'implémentation fournit un type qui implémente http.File , alors il serait trivial pour quiconque, y compris le package http stdlib, de fournir un wrapper autour de la fonction Open , convertissant le type en http.File afin de se conformer à http.FileSystem

@andreynering //go:generate et //go:embed sont cependant très différents. Ce mécanisme peut se produire de manière transparente au moment de la génération car il n'exécutera pas de code arbitraire. Je pense que cela ressemble à la façon dont cgo peut générer du code dans le cadre de go build .

Je ne suis pas convaincu de la complexité d'un bouton "compressé vs pas". Si nous faisons cela, les gens voudront que nous ajoutions un contrôle sur la compression, le niveau de compression, etc. Tout ce que nous devrions ajouter, c'est la possibilité d'intégrer un fichier d'octets bruts.

Bien que j'apprécie la recherche de simplicité, nous devons également nous assurer que nous répondons aux besoins des utilisateurs.

12 des 14 outils répertoriés sur https://tech.townsourced.com/post/embedding-static-files-in-go/#comparison prennent en charge la compression, ce qui suggère qu'il s'agit d'une exigence assez courante.

Je ne suis pas sûr d'être d'accord avec ce raisonnement.

La compression effectuée par les autres bibliothèques est différente de son ajout à cette proposition en ce sens qu'elles ne réduiront pas les performances sur les versions ultérieures, car les alternatives sont généralement générées avant la construction plutôt que pendant la construction.

Les temps de construction faibles sont une valeur ajoutée évidente avec Go sur d'autres langues et la compression échange le temps CPU pour une empreinte de stockage/transfert réduite. Si de nombreux packages Go commencent à exécuter des compressions sur go build nous allons ajouter encore plus de temps de construction que le temps ajouté en copiant simplement les actifs pendant les constructions. Je suis sceptique quant à l'ajout de la compression à cause d'autres qui le font. Tant que la conception initiale n'empêche pas par conception une extension future qui ajoute un support pour, par exemple, la compression, l'insérer là-dedans parce que cela pourrait être quelque chose qui pourrait profiter à certains semble être une couverture inutile.

Ce n'est pas comme si l'intégration de fichiers serait inutile sans compression, la compression est une bonne chose à avoir pour réduire la taille binaire de peut-être 100 Mo à 50 Mo - ce qui est génial, mais pas non plus une rupture claire pour la fonctionnalité de la plupart des applications auxquelles je peux penser . Surtout pas si la plupart des actifs "plus lourds" sont des fichiers tels que des JPEG ou des PNG qui sont déjà assez bien compressés.

Qu'en est-il de garder la compression pour le moment et de l'ajouter si elle est réellement manquée par beaucoup de gens ? (et peut être fait sans frais excessifs)

Pour compléter le commentaire de @sakjur ci-dessus : la compression me semble orthogonale. Je souhaite généralement compresser une archive binaire ou de version complète, et pas seulement les actifs. En particulier lorsque les binaires Go dans Go peuvent facilement atteindre des dizaines de mégaoctets sans aucun actif.

@mvdan Je suppose que l'une de mes préoccupations est que très souvent, lorsque j'ai vu l'intégration se faire avec d'autres prétraitements : minification, compilation dactylographiée, compression de données, traitement d'images, redimensionnement d'images, feuilles de sprite. La seule exception étant les sites Web qui n'utilisent que html/template . Donc, à la fin, vous pourriez finir par utiliser une sorte de "Makefile" de toute façon ou télécharger le contenu pré-traité. En ce sens, je pense qu'un indicateur de ligne de commande fonctionnerait mieux avec d'autres outils que les commentaires.

Je suppose que l'une de mes préoccupations est que très souvent, lorsque j'ai vu l'intégration se faire avec d'autres pré-traitements : minification, compilation dactylographiée, compression de données, traitement d'image, redimensionnement d'image, feuilles de sprite. La seule exception étant les sites Web qui n'utilisent que html/template.

Merci, c'est un point de données utile. Peut-être que le besoin de compression n'est pas aussi courant qu'il y paraît. Si tel est le cas, je suis d'accord qu'il est logique de le laisser de côté.

Ce n'est pas comme si l'intégration de fichiers serait inutile sans compression, la compression est une bonne chose à avoir pour réduire la taille binaire de peut-être 100 Mo à 50 Mo - ce qui est génial, mais pas non plus une rupture claire pour la fonctionnalité de la plupart des applications auxquelles je peux penser .

La taille binaire est un gros problème pour de nombreux développeurs de go (https://github.com/golang/go/issues/6853). Go compresse les informations de débogage DWARF spécifiquement pour réduire la taille binaire, même si cela a un coût en temps de liaison (https://github.com/golang/go/issues/11799, https://github.com/golang/go/ numéros/26074). S'il existait un moyen simple de réduire de moitié la taille binaire, je pense que les développeurs saisiraient cette opportunité (bien que je doute que les gains ici soient presque aussi importants).

Cela n'aide pas vraiment en mode GOPATH, cependant

Peut-être que si vous êtes en mode GOPATH, cette fonctionnalité ne s'applique tout simplement pas car j'imagine que l'équipe Go ne prévoit pas de faire la parité des fonctionnalités pour GOPATH pour toujours ? Il existe déjà des fonctionnalités qui ne sont pas prises en charge dans GOPATH (telles que la sécurité avec la base de données de somme de contrôle, le téléchargement de dépendances via un serveur proxy et la gestion des versions d'importation sémantique)

Comme @bcmills l'a mentionné, avoir le nom de répertoire statique dans un fichier go.mod est un excellent moyen d'introduire cette fonctionnalité dans Go 1.15 car la fonctionnalité peut être automatiquement désactivée dans les fichiers go.mod qui ont une clause <=go1.14.

Cela dit, cela signifie également que les utilisateurs doivent écrire manuellement le chemin du répertoire statique.

Je pense que le répertoire des fournisseurs et les conventions _test.go sont d'excellents exemples de la façon dont ils ont rendu le travail avec Go et ces deux fonctionnalités beaucoup plus faciles.

Je ne me souviens pas de nombreuses personnes ayant demandé l'option de personnaliser le nom du répertoire du fournisseur ou d'avoir la possibilité de changer la convention _test.go en autre chose. Mais si Go n'introduisait jamais la fonctionnalité _test.go, alors les tests dans Go seraient très différents aujourd'hui.

Par conséquent, peut-être qu'un nom moins générique que static donne de meilleures chances de non-collision et donc avoir un répertoire conventionnel (similaire à vendor et _test.go) pourrait être une meilleure expérience utilisateur par rapport aux commentaires magiques.

Exemples de noms potentiellement à faible collision :

• _embed - suit la convention _test.go
• go_binary_assets
• .gobin suit la convention .git
• runtime_files - pour qu'il corresponde à la structure runtime.Files

Enfin, le répertoire vendor été ajouté dans Go 1.5 . Alors, peut-être que ce n'est pas si mal d'ajouter une nouvelle convention maintenant ? ??

Je pense que cela devrait exposer un []byte lecture seule mmap . Juste un accès brut aux pages de l'exécutable, paginé par le système d'exploitation selon les besoins. Tout le reste peut être fourni en plus, avec seulement bytes.NewReader .

Si cela est inacceptable pour une raison quelconque, veuillez fournir ReaderAt pas seulement ReadSeeker ; ce dernier est trivial à construire à partir du premier, mais l'inverse n'est pas aussi bon : il faudrait un mutex pour garder le décalage unique et ruiner les performances.

Ce n'est pas comme si l'intégration de fichiers serait inutile sans compression, la compression est une bonne chose à avoir pour réduire la taille binaire de peut-être 100 Mo à 50 Mo - ce qui est génial, mais pas non plus une rupture claire pour la fonctionnalité de la plupart des applications auxquelles je peux penser .

La taille binaire est un gros problème pour de nombreux développeurs de go (#6853). Go compresse les informations de débogage DWARF spécifiquement pour réduire la taille binaire, même si cela a un coût en temps de liaison (#11799, #26074). S'il existait un moyen simple de réduire de moitié la taille binaire, je pense que les développeurs saisiraient cette opportunité (bien que je doute que les gains ici soient presque aussi importants).

C'est certainement un point juste et je peux voir comment mon argument peut être considéré comme un argument en faveur de la négligence en ce qui concerne la taille des fichiers. Ce n'était pas mon intention. Mon point est plus conforme à l'expédition de cette fonctionnalité sans compression, ce qui serait toujours utile pour certains, et ils pourraient fournir des commentaires et des informations utiles sur la façon d'ajouter correctement la compression d'une manière qui semble correcte à long terme. Les ressources peuvent gonfler d'une manière que les informations de débogage sont peu susceptibles de faire et il est plus facile pour les développeurs de packages installés/importés par d'autres de réduire inutilement les performances de construction si l'implémentation le rend facile.

Une autre option serait de faire de la compression des actifs un indicateur de construction et de laisser le compromis entre la taille et le temps de construction au constructeur plutôt qu'au développeur. Cela rapprocherait la décision de l'utilisateur final du binaire qui pourrait décider si la compression en vaut la peine. Otoh, cela risquerait de créer une surface accrue pour les différences entre le développement et la production, donc ce n'est pas une meilleure méthode qu'autre chose et ce n'est pas quelque chose que je voudrais défendre.

Mon outil d'intégration d'actifs actuel charge le contenu des fichiers d'actifs lorsqu'il est construit avec -tags dev . Une convention comme celle-là serait probablement utile ici aussi ; cela raccourcit considérablement le cycle de développement lorsque, par exemple, vous jouez avec du HTML ou un modèle.

Sinon, l'appelant devra envelopper ce mécanisme de niveau inférieur avec des enveloppes *_dev.go et *_nodev.go et implémenter un chargement non intégré pour le scénario dev . Même pas difficile, mais cette route ne fera que conduire à une explosion d'outils similaire à celle décrite dans le premier commentaire sur ce problème. Ces outils devront faire moins qu'aujourd'hui, mais ils continueront à se multiplier.

Je pense que -tags dev ne pas fonctionner lorsqu'il est exécuté en dehors du module Go serait raisonnable (je ne peux pas savoir d'où charger les actifs).

Qu'en est-il juste d'un go tool embed qui prend des entrées et produit des fichiers de sortie Go dans un format spécial reconnu par l'ordinateur en tant que fichiers intégrés qui pourraient ensuite être accessibles via runtime/emved ou quelque chose du genre. Ensuite, vous pouvez simplement faire un simple //go:generate gzip -o - static.txt | go tool embed -o static.go .

Un gros inconvénient, bien sûr, est que vous devez ensuite valider les fichiers générés.

@DeedleFake ce problème a commencé avec

L'utilisation d'une solution basée sur go:generate gonfle l'historique de git avec une deuxième copie (et légèrement plus grande) de chaque fichier.

Oups. Peu importe. Désolé.

Ce n'est pas comme si l'intégration de fichiers serait inutile sans compression, la compression est une bonne chose à avoir pour réduire la taille binaire de peut-être 100 Mo à 50 Mo - ce qui est génial, mais pas non plus une rupture claire pour la fonctionnalité de la plupart des applications auxquelles je peux penser .

La taille binaire est un gros problème pour de nombreux développeurs de go (#6853). Go compresse les informations de débogage DWARF spécifiquement pour réduire la taille binaire, même si cela a un coût en temps de liaison (#11799, #26074). S'il existait un moyen simple de réduire de moitié la taille binaire, je pense que les développeurs saisiraient cette opportunité (bien que je doute que les gains ici soient presque aussi importants).

S'il y a un besoin, alors les données compressées seront validées et intégrées, et il y aura des packages pour fournir une couche entre runtime.Embed et le consommateur final qui effectue la décompression en ligne.

Et puis dans un an ou deux, il y aura un nouveau problème concernant l'ajout de la compression et cela pourra être réglé à ce moment-là.

Je dis cela comme l'un des 15 standards concurrents lorsque j'ai écrit goembed :)

@tv42 a écrit :

Je pense que cela devrait exposer un []byte lecture seule mmap . Juste un accès brut aux pages de l'exécutable, paginé par le système d'exploitation selon les besoins.

Ce commentaire est facilement raté et incroyablement précieux.

@tv42 ,

Je pense qu'il devrait exposer un [] octet en lecture seule mmap. Juste un accès brut aux pages de l'exécutable, paginé par le système d'exploitation selon les besoins. Tout le reste peut être fourni en plus de cela, avec seulement bytes.NewReader.

Le type qui est déjà en lecture seule est string . Aussi : il fournit une taille, contrairement à io.ReaderAt , et il ne dépend pas de la bibliothèque standard. C'est probablement ce que nous voulons exposer.

Le type qui est déjà en lecture seule est string .

Mais tout l'écosystème de Write etc fonctionne sur []byte . C'est du pragmatisme simple. Je ne vois pas cette propriété en lecture seule être plus un problème que io.Writer.Write docs disant

Write ne doit pas modifier les données de la tranche, même temporairement.

Un autre inconvénient potentiel est que lors de l'intégration d'un répertoire avec go:generate je peux vérifier la sortie de git diff et voir si des fichiers s'y trouvent par erreur. Avec cette proposition - ? Peut-être que la commande go imprimerait la liste des fichiers qu'elle intègre ?

@tv42

Mais tout l'écosystème de Write etc fonctionne sur []byte.

Cependant, html/template fonctionne avec des chaînes.

Go vous permet déjà d'utiliser -ldflags -X pour définir certaines chaînes (utile pour définir la version de git, l'heure de compilation, le serveur, l'utilisateur, etc.), ce mécanisme pourrait-il être étendu pour définir io.Readers au lieu de chaînes ?

@bradfitz Proposez -vous d'utiliser des chaînes ici même pour des données qui ne sont pas du texte ? Il est assez courant d'intégrer de petits fichiers binaires comme des icônes et de petites images, etc.

@tv42 Vous avez dit Write mais je suppose que vous vouliez dire Read . Vous pouvez transformer un string en un io.ReaderAt utilisant strings.NewReader , donc l'utilisation d'une chaîne ne semble pas être un obstacle.

@andreynering Un string peut contenir n'importe quelle séquence d'octets.

Un string peut contenir n'importe quelle séquence d'octets.

Oui, mais son intention première est de contenir du texte et non des données arbitraires. Je suppose que cela peut causer un peu de confusion, en particulier pour les développeurs Go inexpérimentés.

J'ai tout à fait compris l'idée, cependant. Merci de clarifier.

@ianlancetaylor

Read est censé muter la tranche transmise. Write ne l'est pas. Par conséquent, la documentation de Write indique que cela n'est pas autorisé. Je ne vois rien de plus nécessaire que de documenter que les utilisateurs ne doivent pas écrire dans le []byte renvoyé.

Ce n'est pas parce que strings.Reader existe que io.WriteString trouvera une implémentation efficace de l'écriture de chaînes. Par exemple, TCPConn n'a pas WriteString .

Je détesterais que Go inclue une nouvelle fonctionnalité comme celle-ci uniquement pour forcer toutes les données à être copiées juste pour les écrire dans un socket.

De plus, l'hypothèse générale est que les chaînes sont imprimables par l'homme et que []byte ne l'est souvent pas. Mettre des JPEG dans des chaînes causera beaucoup de terminaux en désordre.

@opennota

html/template fonctionne avec des chaînes, cependant.

Ouais, c'est bizarre, il ne prend que les fichiers par chemin d'accès pas comme lecteurs. Deux réponses :

1. Il n'y a aucune raison pour que les données intégrées ne puissent pas avoir les deux méthodes Bytes() []byte et String() string .

2. J'espère que vous n'analysez pas un modèle à chaque requête ; alors que vous devez vraiment envoyer les données d'un JPEG dans un socket TCP pour chaque requête qui le demande.

@tv42 Nous pouvons ajouter des méthodes WriteString au besoin.

Je ne pense pas que l'utilisation la plus courante de cette fonctionnalité sera d'écrire les données non modifiées, donc je ne pense pas que nous devrions optimiser pour ce cas.

Je ne pense pas que l'utilisation la plus courante de cette fonctionnalité sera d'écrire les données non modifiées,

Je pense que l'utilisation la plus courante de cette fonctionnalité sera de servir des actifs Web, images/js/css, non modifiés.

Mais ne me croyez pas sur parole, regardons quelques-uns des importateurs du fileembed de Brad :

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

#fileembed pattern .*\.png



md5-f8b48fccd03599094034bf2b507e9e67



#fileembed pattern .*\.js$

Etc..

Pour les données anecdotiques : je sais que si cela était mis en œuvre, je l'utiliserais immédiatement à deux endroits au travail, et les deux fourniraient un accès non modifié aux fichiers texte statiques. À l'heure actuelle, nous utilisons une étape //go:generate pour convertir les fichiers en chaînes constantes (format hexadécimal).

Je voterais pour le nouveau paquet par opposition à la directive. Beaucoup plus facile à saisir, plus facile à manipuler/gérer et beaucoup plus facile à documenter et à étendre. Par exemple, pouvez-vous facilement trouver la documentation d'une directive Go telle que « go:generate » ? Qu'en est-il de la documentation du package « fmt » ? Vous voyez où je veux en venir ?

Ainsi, Go pourrait simplement avoir son propre outil d'intégration "officiel" qui s'exécute par défaut sur go build

@andreynering Je sais que d'autres gestionnaires de packages et outils de langage le permettent, mais l'exécution de code/commandes arbitraires au moment de la construction est une vulnérabilité de sécurité (pour ce que j'espère être des raisons évidentes).

Deux choses supplémentaires me viennent à l'esprit en pensant à cette fonctionnalité :

• Comment l'intégration de fichiers fonctionnerait-elle automatiquement avec le cache de construction ?
• Cela empêche-t-il les builds reproductibles ? Si les données sont modifiées de quelque manière que ce soit (par exemple en les compressant), cela doit prendre en compte la reproductibilité.

stuffbin , lié dans le premier commentaire, a été conçu pour permettre principalement aux applications Web auto-hébergées d'intégrer des actifs statiques (HTML, JS...). Cela semble être un cas d'utilisation courant.

À l'exception de la discussion sur la compilation / compression, un autre problème est l'absence d'abstraction du système de fichiers dans la stdlib car :

• Sur la machine d'un développeur, les nombreux go run s et builds n'ont pas besoin d'être surchargés par la surcharge d'intégration (tout en compressant éventuellement) les actifs. Une abstraction du système de fichiers permettrait de basculer facilement vers le système de fichiers local pendant le développement.

• Les actifs peuvent changer activement au cours du développement, par exemple, une interface Javascript complète dans une application Web. La possibilité de basculer de manière transparente entre l'intégration et le système de fichiers local au lieu des actifs intégrés permettrait d'éviter la compilation et la réexécution du binaire Go simplement parce que les actifs ont changé.

Edit : Pour conclure, si le package d'intégration pouvait exposer une interface de type système de fichiers, quelque chose de mieux que http.FileSystem, cela résoudrait ces problèmes.

La possibilité de basculer de manière transparente entre l'intégration et le système de fichiers local

Cela peut certainement être mis en œuvre au niveau de l'application et dépasse le cadre de cette proposition, non ?

Cela peut certainement être mis en œuvre au niveau de l'application et dépasse le cadre de cette proposition, non ?

Désolé, je viens de me rendre compte, la façon dont je l'ai formulé est ambiguë. Je ne proposais pas une implémentation de système de fichiers dans le package d'intégration, mais juste une interface, quelque chose de mieux que http.FileSystem . Cela permettrait aux applications d'implémenter n'importe quelle sorte d'abstraction.

Edit : faute de frappe.

@knadh Tout à fait d'accord pour dire que cela devrait fonctionner lorsque vous utilisez également go run , la façon dont Packr gère cela est vraiment sympa. Il sait où se trouvent vos fichiers, s'ils ne sont pas intégrés dans l'application, il les charge alors à partir du disque car il s'attend à ce qu'il s'agisse essentiellement d'un "mode de développement".

L'auteur de Packr a également publié un nouvel outil Pkger qui est plus axé sur les modules Go. Les fichiers qui s'y trouvent sont tous relatifs à la racine du module Go. J'aime beaucoup cette idée, mais Pkger ne semble pas avoir implémenté le chargement de développement local à partir du disque. Une combinaison des deux serait incroyable OMI.

Je ne sais pas s'il est déjà hors d'usage, mais bien que "l'approche du package d'intégration" soit assez magique, elle offre également une certaine efficacité car l'outil peut déduire ce qu'il faut faire du fichier en fonction de l'appel. par exemple, l'API pourrait être quelque chose comme

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

Si l'outil go trouve un appel à FileReaderAt , il sait que les données doivent être décompressées. S'il ne trouve que des appels FileReader , il sait qu'il peut stocker des données compressées. S'il trouve un appel FileBytes , il sait qu'il doit faire une copie, s'il ne trouve que FileString , il sait qu'il peut servir à partir de la mémoire en lecture seule. Etc.

Je ne suis pas convaincu que ce soit un moyen raisonnable de mettre en œuvre cela pour l'outil de go proprement dit. Mais je voulais mentionner ceci, car cela permet d'obtenir les avantages de la compression et de l'intégration sans copie sans avoir de boutons réels.

[edit] aussi, bien sûr, nous ajoutons ces choses supplémentaires après coup, en nous concentrant d'abord sur un ensemble de fonctionnalités plus minimal [/edit]

S'il ne trouve que les appels FileReader...

Cela exclurait l'utilisation des autres méthodes par la réflexion.

[Modifier] En fait, je pense que les implications sont plus larges que cela. Si l'utilisation de FileReaderAt indique que les données doivent être décompressées, alors l'utilisation de FileReaderAt() avec toute entrée non const implique que tous les fichiers doivent être stockés non compressés.

Je ne sais pas si c'est bon ou mauvais. Je pense juste que l'heuristique magique ne sera pas aussi utile que cela puisse paraître à première vue.

Un argument en faveur d'un pragma de commentaire ( //go:embed ) au lieu d'un nom de répertoire spécial ( static/ ) : un commentaire permet d'intégrer un fichier dans l'archive de test d'un package (ou l'archive xtest ) mais pas la bibliothèque testée. Le commentaire doit juste apparaître dans un fichier _test.go .

Je pense que cela résoudrait un problème courant avec les modules : il est difficile d'accéder aux données de test pour un autre package si ce package se trouve dans un autre module. Un package pourrait fournir des données pour d'autres tests avec un commentaire comme //go:embedglob testdata/* dans un fichier _test.go . Le package peut être importé dans un binaire non test standard sans extraire ces fichiers.

@fd0 ,

Comment l'intégration de fichiers fonctionnerait-elle automatiquement avec le cache de construction ?

Cela fonctionnerait encore. Les hachages du contenu du fichier intégré seraient mélangés à la clé de cache.

Serait-il possible (ou même une bonne idée) d'avoir un module/package/mécanisme qui serait pratiquement transparent, car depuis l'intérieur de votre application, vous essayez simplement d'ouvrir un chemin comme

internal://static/default.css

et les fonctions de fichier liront les données à l'intérieur du binaire ou à partir d'un autre emplacement
ex Package.Mount("internal[/<folder>.]", binary_path + "/resources/")

pour créer "internal://" avec tous les fichiers dans le binaire, revenir au chemin exécutable / ressources / si en mode dev ou si le fichier n'est pas trouvé dans le binaire (et peut-être lancer un avertissement ou quelque chose à des fins de journalisation)

Cela permettrait par exemple d'avoir

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

Il est probablement préférable de verrouiller l'emplacement alternatif sur le chemin de l'exécutable en mode "release", mais détendez-le en mode dev (autorisez uniquement les dossiers dans go_path ou quelque chose comme ça)

Par défaut, le package "monte" internal:// ou un autre mot-clé mais permet à l'utilisateur de le renommer s'il le souhaite... ex .ReMount("internal","myCustomName") ou quelque chose comme ça.

Une autre chose... serait-il judicieux de vérifier l'heure de la dernière modification/modification sur un autre emplacement et de remplacer automatiquement le fichier interne s'il existe un tel fichier en dehors de l'application (peut-être avoir un indicateur permettant cela, configurable par le programmeur avant la construction)
Cela peut être souhaité pour les correctifs d'applications super rapides, où vous ne voulez pas attendre qu'une nouvelle version soit créée et distribuée. déposer.

Sous Windows, serait-il possible ou logique d'utiliser des ressources (comme dans le blob de données binaires dans une ressource)
Et un peu sans rapport, mais peut-être que ce package pourrait également traiter des icônes de regroupement dans l'exécutable, ou des données manifestes, ou peut-être même d'autres ressources ? Je me rends compte que c'est uniquement Windows...
J'imagine que le constructeur pourrait enregistrer les dernières dates de modification/modification des fichiers dans les dossiers alternatifs et ne déclencher un "créer un blob de données" que si un fichier change et mettre le blob en cache quelque part.
Peut-être ne créer qu'un fichier "cache" si l'utilisateur choisit d'activer la compression sur ces fichiers groupés (s'il est finalement décidé de les compresser) ... si la compression est choisie, seul le fichier particulier qui a été modifié devra être recompressé au moment de la construction , les autres fichiers seraient simplement copiés dans le binaire à partir du cache.

Un problème que je vois est que si le package autorise les noms personnalisés, il devrait avoir une sorte de liste noire, car il n'autorise pas "udp, file, ftp, http, https et divers autres mots clés populaires".

En ce qui concerne le stockage sous forme de tableau / chaîne d'octets ou de compression ... à mon humble avis, quelle que soit la décision prise, cela devrait laisser de la place pour une mise à jour facile à l'avenir ... ex. les noms de fichiers mais permettent d'ajouter facilement de la compression à l'avenir (ex méthode zlib, lzma, taille compressée, taille non compressée s'il est nécessaire d'allouer suffisamment de mémoire pour décompresser des morceaux, etc.

Personnellement, je serais heureux si l'exécutable pouvait être compressé avec UPX ou équivalent, je suppose que le binaire serait décompressé en mémoire et que tout fonctionnerait.

Quelques réflexions qui se rapportent indirectement :

• J'aime l'approche package embed pour son utilisation de la syntaxe Go
• Je pense que le besoin de compression et d'autres manipulations ne concerne pas la taille binaire, il s'agit de vouloir stocker uniquement la forme de contenu la plus conviviale pour les diff dans un référentiel, pour qu'il n'y ait pas d'état "désynchronisé" où quelqu'un oublie de se régénérer et validez une forme compressée lors de la modification de la "source" et pour que le package reste "go gettable". Sans aborder ces points, nous ne résolvons que le problème de la standardisation, ce qui peut être acceptable, mais ne semble pas idéal.
• Je pense que nous pourrions contourner la nécessité pour la chaîne d'outils de prendre en charge activement des compressions/transformations spécifiques si l'interaction embed peut éventuellement fournir un "codec". Comment définir exactement le codec dépend de la syntaxe d'intégration, mais j'imagine quelque chose comme

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
}

Cela peut couvrir des cas d'utilisation très spécifiques, comme celui-ci :

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
}

L'utiliser pourrait ressembler à

// go:embed file.name NewJSONShrinker

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

ou éventuellement

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

Dans la seconde forme, il y a la complication dont la chaîne d'outils a besoin pour comprendre statiquement quel codec utiliser, car elle doit effectuer l'étape Encode au moment de la compilation. Nous devrions donc interdire toute valeur de codec qui ne peut pas être facilement déterminée au moment de la compilation.

Compte tenu de ces deux options, je pense que je choisirais le commentaire magique plus les codecs. Il en résulte une fonctionnalité plus puissante qui répond à tous les objectifs énoncés ici. De plus, je ne pense pas que les commentaires magiques soient inacceptables ici. Nous les tolérons déjà via go:generate à cette fin en ce moment. Si quoi que ce soit, on pourrait considérer le paquet magique à lui seul comme un écart par rapport aux idiomes actuels. L'écosystème Go n'a actuellement pas beaucoup de fonctionnalités qui permettent à un fichier source d'indiquer à la chaîne d'outils d'utiliser des fichiers source supplémentaires, et je pense que le seul qui n'est pas un commentaire magique en ce moment est le mot-clé import .

Si nous faisons de la compression, il n'y aura pas du tout de boutons de type de codec ou de niveau de compression. C'est-à-dire que le fait d'avoir n'importe quel bouton est le plus grand argument pour ne pas prendre en charge la compression du tout.

Le seul choix que je voudrais exposer, le cas échéant, est : accès aléatoire ou non. Si vous n'avez pas besoin d'un accès aléatoire, l'outillage et l'environnement d'exécution peuvent choisir la compression appropriée et ne pas l'exposer aux utilisateurs. Et cela changera probablement / s'améliorera avec le temps.

Mais je suis venu du côté de @rsc pour ne pas avoir de compression à cause d'une réalisation que j'avais : le contenu même qui est le plus compressible (HTML, JS, CSS, etc.) est le contenu sur lequel vous voudriez toujours un accès aléatoire (à être servi via, disons, http.FileServer , qui prend en charge les demandes de plage)

Et en regardant la taille combinée du HTML/CSS/JS de Perkeep que nous intégrons, c'est 48 Ko non compressé. Le binaire du serveur Perkeep fait 49 Mo. (J'ignore la taille des images intégrées car elles sont déjà compressées.) Il semble donc que cela n'en vaut pas la peine, mais cela pourrait être ajouté plus tard.

D'après une discussion avec @rsc , il semble que nous pourrions faire un mélange des approches ci-dessus :

Dans l'exécution du package,

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(...) { ...}

Ensuite dans ton code :

package yourcode

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

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

Ensuite, l'outil cmd/go analyserait les commentaires go:embed et globait ces modèles + hacherait ces fichiers et les enregistrerait avec le runtime, en utilisant &website .

L'environnement d'exécution aurait effectivement une carte de chaque adresse de fichier avec son contenu et son emplacement dans l'exécutable du fichier (ou quels sont leurs noms de section ELF/etc). Et peut-être qu'ils prennent ou non en charge l'accès aléatoire, si nous finissons par effectuer une compression.

@gdamore ,

Juste une autre ride ici - j'ai un projet différent qui utilise le code source DTrace (intégré). Ceci est sensible aux différences entre n et rn.
...
Si divers munging ne font pas l'affaire, alors c'est un argument contre l'utilisation de cette nouvelle fonctionnalité.

Vous pouvez également munge au moment de l'exécution pour supprimer tous les retours chariot qui sont intégrés à partir des utilisateurs Windows exécutant go install. J'ai écrit ce filtre io.Reader plusieurs fois.

Mais je suis venu du côté de @rsc pour ne pas avoir de compression à cause d'une réalisation que j'avais : le contenu même qui est le plus compressible (HTML, JS, CSS, etc.) est le contenu sur

La compression et l'accès aléatoire ne s'excluent pas totalement. Voir par exemple une discussion ici : https://stackoverflow.com/questions/429987/compression-formats-with-good-support-for-random-access-within-archives

La compression et l'accès aléatoire ne s'excluent pas totalement

Oui, si nous voulions une recherche à gros grains avec un peu de frais généraux pour arriver à la bonne position. J'ai travaillé dans cet espace avec le format stargz de CRFS . Mais je crains que les frais généraux ne soient suffisamment importants pour que nous ne voulions pas le faire automatiquement pour les gens. Je suppose que vous pouvez également le gonfler paresseusement en mémoire (et pouvoir le déposer sur les GC, comme un sync.Pool), mais cela ne semble pas en valoir la peine.

Je crains que les frais généraux ne soient suffisamment importants pour que nous ne voulions pas le faire automatiquement pour les gens.

Assez juste. La question importante est de savoir si nous préférerions une API qui nous permette de changer d'avis à moindre coût plus tard, si les besoins changent ou si les expériences montrent que la surcharge est acceptable.

@bradfitz bon point. Et je peux certainement le faire. FWIW, dans mon référentiel, j'ai également configuré git pour qu'il soit moins toxique lors de la visualisation des fichiers .d. Néanmoins, je trouve que la propriété des chaînes intégrées avec des guillemets arrière est utile, en ce sens qu'elle est prévisible et non soumise aux caprices de git ou du système.

Ce à quoi je voulais en venir avec l'idée du codec, c'est que la compression n'est pas la seule transformation que l'on pourrait souhaiter et qu'un type de codec fourni par l'utilisateur permet à la chaîne d'outils d'ignorer les indicateurs autres que "quel codec". Tout niveau de compression, ou l'algorithme du tout, compression ou autre, devrait être spécifique au codec utilisé. Je suis tout à fait d'accord qu'essayer de "prendre en charge la compression" dans le sens de fournir un ensemble spécifique de formats et de boutons serait une course folle avec toutes les variations que les gens pourraient demander. En fait, je serais très enthousiasmé par les utilisations peu courantes, comme le prétraitement des données i18n, peut-être, ou le traitement des ensembles de données comme dans latlong , donc je pense qu'il vaut toujours la peine d'envisager des options autour de cela.

J'ai pensé à une autre façon d'offrir la même flexibilité qui pourrait être plus agréable. La directive // go:embed pourrait être une invocation de commande, tout comme // go:generate . Pour le cas le plus simple, quelque chose comme

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

La principale différence étant, bien sûr, que la sortie standard de l'appel de commande est intégrée sous le nom fourni. L'exemple utilise également un package factice avec go run pour montrer comment il serait probable que la commande soit indépendante du système d'exploitation, car cat peut ne pas être disponible partout où Go compile.

Cela prend en charge l'étape « encoder » de la transformation, et peut-être que la tâche de l'étape « décoder » peut être laissée à l'utilisateur. Le package runtime/embed peut simplement fournir les octets que l'utilisateur a demandé à la chaîne d'outils d'intégrer, quel que soit l'encodage. C'est bien parce que l'utilisateur sait quel devrait être le processus de décodage.

Un gros inconvénient est que je ne vois pas de bon moyen d'intégrer un glob de plusieurs fichiers de cette façon, au-delà des octets intégrés étant un zip ou quelque chose. Cela pourrait en fait être suffisant, car un glob pourrait toujours être utilisé par une commande zip, et c'est du côté de la définition que vous vous souciez vraiment du glob. Mais nous pourrions également tirer deux fonctionnalités de cette proposition, l'une pour faire de l'embarqué simple et l'autre pour exécuter un générateur-embarqué.

Un inconvénient possible qui m'est venu est qu'il ajoute une étape ouverte dans la construction, en supposant que les intégrations doivent être gérées par go build et ne nécessitent pas une invocation supplémentaire de la chaîne d'outils comme le fait go generate . Je pense que c'est bien, cependant. Peut-être que l'outil peut gérer son propre cache pour éviter de répéter des opérations coûteuses, ou peut-être qu'il peut communiquer avec la chaîne d'outils pour utiliser le cache de Go. Cela ressemble à un problème qui peut être résolu et correspond au thème général de go build faire plus pour nous (comme récupérer des modules).

L'un des objectifs de ce projet est-il de garantir que les versions Go ne nécessitent aucun outil externe et aucune ligne go:generate ?

Sinon, il semble utile de garder les choses simples et de ne prendre en charge qu'une tranche ou une chaîne d'octets, car si l'utilisateur souhaite une compression avec beaucoup de boutons, il peut le faire dans son fichier make (ou similaire), générer une ligne, etc. avant de construire de toute façon, il ne semble donc pas utile de les ajouter à quel que soit le résultat de cette proposition.

Si ne pas exiger Make ou similaire est un objectif, alors je suppose qu'il peut être judicieux d'utiliser la compression, mais personnellement, je ferais aussi bien d'utiliser Make, go generate, etc. .

@SamWhited ,

L'un des objectifs de ce projet est-il de garantir que les versions Go ne nécessitent aucun outil externe et aucune ligne go:generate ?

Oui.

Si les gens veulent utiliser go:generate ou Makefiles ou d'autres outils, ils ont des dizaines de choix aujourd'hui.

Nous voulons quelque chose de portable, sûr et correct qui fonctionne par défaut. (et pour être clair : safe signifie que nous ne pouvons pas exécuter de code arbitraire au moment de l'installation, pour la même raison que go:generate ne s'exécute pas par défaut)

@stephens2424

Je pense que nous pourrions contourner la nécessité pour la chaîne d'outils de prendre en charge activement des compressions/transformations spécifiques si l'interaction d'intégration peut éventuellement fournir un "codec".

Aucune exécution de code arbitraire pendant go build .

Pas d'exécution de code arbitraire pendant go build.

Oui, je vois ça maintenant. Je suppose qu'il n'y a aucun moyen de réconcilier le fait d'avoir uniquement des fichiers "source" dans un dépôt, de vouloir des fichiers "traités" intégrés, d'avoir le package "go gettable", _et_ de garder go build simple et sûr. Je suis toujours en faveur de la standardisation ici, mais j'espérais avoir mon gâteau et le manger aussi, je suppose. Ça vaut le coup! Merci d'avoir attrapé le problème !

@flimzy

Cela exclurait l'utilisation des autres méthodes par la réflexion.

Il n'y a pas de méthodes dans ce que j'ai mentionné, seulement des fonctions. Ils ne sont pas détectables au moment de l'exécution et il n'y a aucun moyen de les référencer sans les mentionner par leur nom dans la source. Et notez que les valeurs d'interface renvoyées par les différentes fonctions ne doivent pas nécessairement être du même type - en effet, je m'attendrais à ce qu'elles soient soit des types non exportés avec exactement la méthode requise pour implémenter cette interface, soit une instance de *strings.Reader etc., tout ce qui aurait du sens dans le contexte.

On peut cependant soutenir que l'idée souffre de la transmission des fonctions exportées du package d'intégration en tant que valeurs. Bien que même cela ne soit probablement pas un problème - la signature contient un type non exporté (voir ci-dessous), vous ne pouvez donc pas déclarer une variable, un argument ou un retour de leur type. Vous pouvez les transmettre à reflect.ValueOf eux-mêmes, en théorie. Je ne sais même pas si cela vous permettrait de les appeler (vous auriez toujours à construire une valeur de leur type de paramètre, qui n'est pas exportée. Je ne sais pas si reflect le permet).

Mais quoi qu'il en soit : il serait toujours possible (et le plus simple) d'être simplement pessimiste au cas où une fonction de niveau supérieur de embed serait utilisée comme valeur et assumerait les restrictions qu'elle crée sur tous les fichiers intégrés. Ce qui voudrait dire que si vous décidez de faire des choses extrêmement bizarres et inutiles avec le package embed, vous perdez certaines optimisations (sur lesquelles nous ne faisons pas nécessairement de promesses de toute façon). Semble juste.

En fait, je pense que les implications sont plus larges que cela. Si l'utilisation de FileReaderAt indique que les données doivent être décompressées, alors l'utilisation de FileReaderAt() avec toute entrée non const implique que tous les fichiers doivent être stockés non compressés.

Cela n'a aucun sens d'autoriser des entrées non constantes, car le nom de fichier doit être connu de manière statique pour effectuer l'intégration. Il était cependant imprécis de ma part d'utiliser string comme type de paramètres de nom de fichier : ils auraient dû vraiment être un type filename string non exporté et ne pas être utilisés comme autre chose que des arguments de fonction. De cette façon, il est impossible de passer quoi que ce soit qui ne soit pas une constante de chaîne non typée.

@Merovius

Cela n'a aucun sens d'autoriser des entrées non constantes

Je pense que nous parlons de choses différentes. Je veux dire les entrées des fonctions d'accès (c'est- FileReaderAt() dire

Et mon propos est le suivant : supposons que nous ayons incorporé 100 fichiers, mais que nous ayons un appel FileReaderAt(filename) , où filename n'est pas constant ; il n'y a aucun moyen de savoir lesquels (le cas échéant) des fichiers intégrés seront accessibles de cette manière, donc tous doivent être stockés non compressés.

@flimzy, nous parlions de la même chose, je ne pensais vraiment pas que les noms de fichiers non const auraient du sens :) Ce qui, à bien y penser, était faux et un oubli. Désolé pour ça. Les fonctionnalités permettant de regrouper ou d'inclure des répertoires entiers, puis de les parcourir, sont en fait assez importantes, oui. Pense encore cela pourrait être résolu - par exemple , en prenant la décision par collection (dir / glob) et ne permettant de sélectionner ceux des noms constants - mais comme je l' ai dit: Il est pas vraiment une API que je considère super approprié pour l'outil Go à cause de comme c'est magique. Donc, entrer dans les mauvaises herbes comme ça donne probablement au concept plus d'espace dans la discussion qu'il ne le mérite :)

Un autre cas que je n'ai pas vu dans les messages précédents et qui m'a fait envisager d'intégrer un fichier dans un binaire Go était l'impossibilité de distribuer correctement un package wrapper d'une bibliothèque partagée C en utilisant go build/install (la bibliothèque partagée reste dans le sources).

Je ne l'ai pas fait au final mais cela me ferait certainement reconsidérer ma décision pour cette affaire. La bibliothèque C a en effet beaucoup de dépendances qui seraient plus faciles à distribuer en tant que bibliothèque partagée. Cette bibliothèque partagée pourrait être intégrée par les liaisons Go.

Wow!!!

@Julio-Guerra
Je suis sûr que vous auriez toujours à les extraire sur le disque, puis à utiliser dlopen et dlsym pour appeler les fonctions C.

Edit: J'ai un peu mal compris votre message, je viens de réaliser que vous parlez de créer un binaire pour la distribution

En dehors des ressources statiques http, pour les blobs intégrés dont vous avez besoin dans un pointeur vers la mémoire, il serait bien d'avoir une fonction qui renvoie le pointeur vers la mémoire intégrée déjà en cours. Sinon, il faudrait allouer une nouvelle mémoire et faire une copie à partir du io.Reader. Cela consommerait deux fois plus de mémoire.

@glycerine , encore une fois, c'est un string . Un string est un pointeur et une longueur.

Ne serait-il pas formidable d'avoir juste un moyen de marquer le code à exécuter au moment de la compilation et de fournir le résultat au moment de l'exécution. De cette façon, vous pouvez lire n'importe quel fichier, le compresser si vous le souhaitez au moment de la compilation et au moment de l'exécution, vous pouvez y accéder. Cela fonctionnerait pour certains calculs comme cela fonctionnerait pour le préchargement du contenu du fichier.

@burka comme dit précédemment dans le fil, go build n'exécutera pas de code arbitraire.

@burka , c'est explicitement hors de portée. Cette décision (pas d'exécution de code au moment de la compilation) a été prise il y a longtemps et ce n'est pas le bogue pour changer cette politique.

Un effet secondaire de cette proposition est que les proxys go ne peuvent jamais optimiser les fichiers qu'ils stockent pour qu'ils ne soient que des fichiers go. Un proxy doit stocker un référentiel entier car il ne saura pas si le code Go intègre l'un des fichiers non-Go.

Je ne sais pas si les proxys optimisent déjà pour cela, mais c'est faisable un jour, ils le voudront peut-être.

@leighmcculloch Je ne pense pas non plus que ce soit le cas aujourd'hui. Tous les fichiers non Go d'un package Go doivent être inclus dans les archives du module, car ils peuvent être requis pour go test . Vous pouvez également avoir des fichiers C pour cgo, comme autre exemple.

C'est une direction passionnante, nous en avons certainement besoin pour nos cas d'utilisation.

Cela dit, j'ai l'impression qu'il existe différents cas d'utilisation avec des exigences différentes, mais la plupart de ceux qui commentent _comment_ ils pensent que cela devrait être fait envisagent implicitement leurs propres cas d'utilisation mais ne les définissent pas explicitement.

Cela pourrait être utile - du moins vraiment utile pour moi - si nous pouvions délimiter les différents cas d' les défis que chaque cas d'utilisation présente.

Par exemple, notre cas d'utilisation principal consiste à intégrer HTML+CSS+JS+JPG+etc afin que lorsque l'application go est exécutée, elle puisse écrire ces fichiers dans un répertoire de manière à ce qu'ils puissent être servis par un http.FileServer . Étant donné ce cas d'utilisation, la plupart des commentaires que j'ai lus sur les lecteurs et les écrivains m'étaient étrangers car nous n'avons pas besoin d'accéder aux fichiers depuis Go, nous laissons simplement go-bindata copier sur le disque _(bien que peut-être existe-t-il un moyen de tirer parti de meilleures techniques que nous n'avons tout simplement pas encore réalisé que nous devrions envisager.)_

Mais nos défis sont les suivants : nous utilisons généralement GoLand avec son débogueur et travaillerons sur l'application Web en apportant des modifications continues. Ainsi, pendant le développement, nous avons besoin de http.FileServer pour charger les fichiers directement depuis notre répertoire source. Mais lorsque l'application s'exécute, http.FileServer doit lire ces fichiers à partir du répertoire dans lequel les fichiers ont été écrits par la solution d'intégration. Ce qui signifie que lorsque nous compilons, nous devons exécuter go-bindata pour mettre à jour les fichiers, puis les archiver dans Git. Et tout cela est généralement réalisable avec go-bindata , bien que certainement pas une idée.

Cependant, à d'autres moments, nous devons réellement exécuter un exécutable compilé, afin que nous puissions attacher un débogueur au programme en cours d'exécution tout en laissant ce programme charger les fichiers à partir du répertoire source et non du répertoire où le fichier intégré est écrit par go-bindata . Actuellement, nous n'avons pas de bonne solution pour cela.

Voilà donc nos cas d'utilisation et nos défis. Peut-être que d'autres pourraient définir explicitement les autres cas d'utilisation et l'ensemble de défis associés, afin que ces discussions puissent explicitement aborder les différents espaces problématiques et/ou indiquer explicitement que cet effort ne répondra pas aux besoins spécifiques d'un espace problématique donné ?

Merci d'avance de considérer.

Comme je ne le vois pas mentionné comme cas d'utilisation, nous en bénéficierions également pour notre répertoire de modèles auxquels nous accédons via template.ParseFiles.

Je trouverais que l'approche la plus propre serait une méthode d'inscription via go.mod . Cela garantirait qu'il était rétrocompatible (car les projets existants devraient choisir de l'utiliser) et permettrait aux outils (tels que les proxys go) de déterminer quels fichiers sont nécessaires. La commande go mod init pourrait être mise à jour pour inclure une version par défaut pour les nouveaux projets afin de faciliter son utilisation à l'avenir.

Je peux voir des arguments pour que le répertoire soit un nom standard (si nous avons besoin d'un opt-in, il peut s'agir d'un nom plus propre / plus simple) ou que le nom du répertoire soit défini dans go.mod lui-même et permet aux utilisateurs de choisissez le nom (mais ayant une valeur par défaut fournie par go mod init .

Dans mon esprit, une solution comme celle-ci atteint un équilibre entre facilité d'utilisation et moins "magique".

@jayconrod a écrit :

Un argument en faveur d'un pragma de commentaire (//go:embed) au lieu d'un nom de répertoire spécial (static/) : un commentaire nous permet d'intégrer un fichier dans l'archive de test pour un paquet (ou l'archive xtest) mais pas la bibliothèque sous test.

C'est une très belle observation. Bien que si nous voulions utiliser le nom de répertoire spécial, nous pourrions utiliser un mécanisme familier : static pour toutes les versions, static_test pour les versions de test, static_amd64 pour les versions amd64, et bientôt. Cependant, je ne vois pas de moyen évident de fournir une prise en charge arbitraire des balises de construction.

Il pourrait y avoir un fichier manifeste dans le répertoire statique (par défaut lorsqu'un manifeste vide est tout inclus sauf le manifeste) qui inclut des globs et permet de spécifier des balises de construction et peut-être une compression ultérieure, etc.

Un avantage est que si go list atteint un répertoire contenant un manifeste, il peut ignorer cet arbre à la #30058

Un inconvénient est que cela pourrait devenir très difficile et non merci

Un mécanisme simple à bouton zéro pour regrouper des fichiers dans un package pourrait être un répertoire spécial go.files dans un répertoire de package (similaire à go.mod dans un module). L'accès serait limité à ce package, à moins qu'il ne choisisse d'exporter un symbole.

Edit : proposition runtime/files fonction unique :

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)
}

L'approche import "C" a déjà créé un précédent pour les chemins d'importation "magiques". OMI, cela a plutôt bien fonctionné.

Comme je ne le vois pas mentionné comme cas d'utilisation, nous en bénéficierions également pour notre répertoire de modèles auxquels nous accédons via template.ParseFiles.

Il y a un autre défi : alors que le binaire peut contenir tous les fichiers nécessaires, ces mêmes fichiers seraient les valeurs par défaut que je fournis en tant que développeur. Cependant, les modèles comme par exemple les mentions légales ou les politiques de confidentialité doivent être personnalisables par l'utilisateur final. Autant que je sache, cela signifie qu'il doit y avoir un moyen d'exporter mes fichiers par défaut, puis de laisser le binaire utiliser les fichiers personnalisés au moment de l'exécution, ou de remplacer les versions intégrées par les versions personnalisées.

Je pense que cela pourrait être fait en fournissant une API avec des fonctions pour « exporter » et « remplacer » une ressource intégrée. Le développeur pourrait alors fournir des options de ligne de commande à l'utilisateur final (en utilisant en interne les appels d'API mentionnés).

Tout cela, bien sûr, basé sur l'hypothèse qu'il y aura en fait une sorte d'intégration qui faciliterait certainement le déploiement.

Merci d'avoir ouvert le sujet. Au travail, nous avons pensé à la même idée de fonctionnalité, car nous avons besoin d'intégrer des fichiers dans à peu près tous les projets Golang. Les bibliothèques existantes fonctionnent bien, mais je pense que c'est une fonctionnalité que Golang réclame. C'est un langage fait pour se transformer en un seul binaire statique. Il devrait adopter cela en nous permettant de charger les fichiers d'actifs requis dans le binaire, avec une API universelle et conviviale pour les développeurs.

Je veux juste fournir rapidement mes détails de mise en œuvre préférés. Plusieurs personnes ont parlé de fournir automatiquement une API pour lire les fichiers intégrés, au lieu d'avoir besoin d'un autre signal comme un commentaire magique. Je pense que cela devrait être la voie à suivre, car cela offre une syntaxe programmatique familière à l'approche. Opter pour un package spécial, peut-être runtime/embed comme mentionné précédemment, satisferait cela et permettrait une extensibilité facile à l'avenir. Une implémentation comme la suivante serait la plus logique pour moi :

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{}) 
}

L'utilisation de ce package quelque part dans votre code devrait déclencher le compilateur pour fournir ce fichier au runtime en l'incorporant automatiquement.

// 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)

De plus, je pense que les problèmes de sécurité et de reproductibilité ne devraient pas poser de problème si nous limitons l'importation à des fichiers situés ou éventuellement à 1 niveau de répertoire en dessous du répertoire go.mod, qui a également déjà été mentionné précédemment dans le fil de discussion. Les chemins d'intégration absolus seraient résolus par rapport à ce niveau de répertoire.

Ne pas accéder aux fichiers pendant le processus de compilation générera une erreur de compilation.

Il est également possible de créer une archive zip derrière un binaire, afin qu'il puisse effectivement devenir un binaire auto-extractible. Peut-être que cela est utile dans certains cas d'utilisation ? A fait cela comme une expérience ici: https://github.com/sanderhahn/gozip

Go a déjà des « données de test ». Les tests unitaires utilisent des IO régulières pour faire ce qu'ils veulent faire. La portée du test signifie que le contenu n'est pas expédié. C'est tout ce qu'il y a à savoir, pas de fioritures, pas de magie, pas de logique de conteneur compressé, pas d'indirections configurables, pas de META-INF. Beau, simple, élégant. Pourquoi ne pas avoir un dossier « données » pour les dépendances de portée d'exécution groupées ?

Nous pouvons facilement analyser des projets Go existants dans Github ea et proposer un certain nombre de projets qui utilisent déjà un dossier « données » et nécessitent donc une adaptation.

Autre chose qui n'est pas claire pour moi. Pour la discussion d'un répertoire static , il n'est pas clair pour moi à 100% si nous parlons d'un répertoire static _source_ , ou d'un répertoire static où les fichiers seront mis à disposition _at runtime_ ?

Et cette distinction est particulièrement importante car elle concerne le processus de développement et le code de débogage en cours de développement.

@mikeschinkel, il ressort assez clairement du message d'origine que l'intégration se produirait au moment de la construction :

faire go install / go build faire l'intégration automatiquement

Le message d'origine et certains des commentaires ci-dessus parlent également d'un mode "dev" pour charger les fichiers au moment de l'exécution.

@mvdan Merci pour la réponse. Vous pensez donc que cela signifie que le répertoire /static/ proposé serait relatif à la racine du référentiel d'applications, du référentiel de packages et/ou éventuellement des deux ?

Et cet emplacement des fichiers d'exécution dépendrait totalement de l'endroit où le développeur voulait les placer ?

Si tout cela est vrai - et cela semble logique - il serait utile que les programmes compilés avec des informations de débogage puissent éventuellement charger des fichiers à partir de leur emplacement source pour faciliter le débogage sans beaucoup de logique et de code supplémentaires - et non standardisés.

Quelques personnes ont mentionné les proxys de module ci-dessus. Je pense que c'est un excellent test décisif pour une bonne conception de cette fonctionnalité.

Il semble possible aujourd'hui, sans exécuter de code utilisateur, d'implémenter aujourd'hui un proxy de module fonctionnel qui supprime les fichiers qui ne sont pas utilisés dans la construction. Certaines des conceptions ci-dessus signifient que les proxys de module doivent exécuter le code utilisateur pour déterminer quels fichiers statiques doivent également être inclus.

Les gens ont également mentionné go.mod comme opt-in.

Idée : spécification dans le fichier go.mod ? Facilite l'analyse des autres outils.

module github.com/foo/bar

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

Cela créerait un package au moment de la compilation avec les données du fichier. La syntaxe Glob peut être agréable ici, mais peut-être que simplifier et n'incorporer que des répertoires est suffisant. (A part : +1 pour la syntaxe ** glob.)

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

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

Quelque chose comme StripPrefix pourrait être sympa ici mais pas nécessaire. Créez facilement un package wrapper qui utilise les chemins de fichiers que vous souhaitez.

On pourrait encore simplifier :

module github.com/foo/bar

data ./static/*.tmpl.html

import "runtime/moddata"

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

Mais il est un peu peu intuitif que moddata ait un comportement différent selon le package/module appelant. Cela rendrait plus difficile l'écriture d'aides (par exemple, le convertisseur http.Filesystem)

Il semble possible aujourd'hui, sans exécuter de code utilisateur, d'implémenter aujourd'hui un proxy de module fonctionnel qui supprime les fichiers qui ne sont pas utilisés dans la construction. Certaines des conceptions ci-dessus signifient que les proxys de module doivent exécuter le code utilisateur pour déterminer quels fichiers statiques doivent également être inclus.

Je ne pense pas qu'il y aurait un changement significatif ici. En particulier, le code C pourrait déjà inclure n'importe quel fichier dans l'arborescence, donc un proxy de module qui voudrait faire cela devrait analyser C. Il semble qu'à ce stade, quels que soient les commentaires magiques ou l'API que nous introduirons, ce sera un petit pas.

Certaines des conceptions ci-dessus signifient que les proxys de module doivent exécuter le code utilisateur pour déterminer quels fichiers statiques doivent également être inclus.

Je pense qu'il est assez clair que "l'outil go ne doit pas exécuter de code utilisateur pendant la construction" est une ligne tracée dans le sable qui ne sera pas franchie ici. Et si l'outil go ne peut pas exécuter le code utilisateur, alors il doit être possible de dire quels fichiers inclure sans lui.

J'ai essayé de condenser mes diverses réflexions sur ce cas d'utilisation en quelque chose de convaincant, et donc un gros +1 à ce que @broady a suggéré. Je pense que cela résume en grande partie ce que j'ai pensé. Cependant, je pense que le mot-clé devrait être le verbe embed au lieu du nom data .

1. Les fichiers intégrés ressemblent à quelque chose qui devrait être importé plutôt que d'avoir simplement un commentaire spécial ou un package magique. Et dans un projet Go, le fichier go.mod est l'endroit où un développeur peut spécifier les modules/fichiers nécessaires, il est donc logique de l'étendre pour prendre en charge l'intégration.

2. De plus, une collection de fichiers intégrés me semble plus utile et réutilisable si un package qui pourrait être inclus plutôt que quelque chose d'ad-hoc ajouté à un projet Go en utilisant une syntaxe unique. L'idée ici est que si les intégrations étaient implémentées sous forme de packages, les gens pourraient les développer et les partager via Github et d'autres pourraient les utiliser dans leurs projets. Imaginez des packages gérés par la communauté et gratuits sur GitHub contenant :

   une. Fichiers pour les pays où chaque fichier contient tous les codes postaux de ce pays,
   b. Un fichier avec toutes les chaînes d'agent utilisateur connues pour identifier les navigateurs,
   c. Images du drapeau de chaque pays du monde,
   ré. Informations d'aide détaillées décrivant les erreurs courantes dans un programme Go,
   e. etc...

3. Un nouveau schéma d'URL tel que goembed:// - ou peut -

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

Avec les concepts ci-dessus, rien ne ressemble à de la _"magie"_ ; tout serait géré avec élégance par un mécanisme qui semble avoir été conçu à cet effet. Il n'y aurait besoin que de très peu d'extensions ; un nouveau verbe dans go.mod et un nouveau schéma d'URL qui serait reconnu en interne par Go. Tout le reste serait fourni tel quel depuis Go.

Ce que je fais maintenant

J'utilise code.soquee.net/pkgzip pour cela en ce moment (c'est un fork de statik qui modifie l'API pour éviter l'état global et les effets secondaires d'importation). Mon flux de travail normal (au moins dans une application Web) consiste à intégrer des ressources regroupées dans un fichier ZIP, puis à les servir à l'aide de golang.org/x/tools/godoc/vfs/zipfs et golang.org/x/tools/godoc/vfs/httpfs .

go:embed approche

Il y a deux choses qui pourraient m'empêcher d'adopter l'approche go:embed :

1. Le code généré n'apparaîtra pas dans la documentation
2. Les actifs peuvent être dispersés dans toute la base de code (cela est vrai de l'utilisation d'outils externes et de go:generate également, c'est pourquoi je préfère généralement utiliser un makefile pour générer divers ensembles d'actifs avant la construction, puis je peut les voir tous dans le makefile)

Il y a aussi un problème que je n'inclus pas ci-dessus, car il peut s'agir pour certains d'une fonctionnalité selon laquelle le fait que les actifs fassent partie d'un package (par opposition à l'ensemble du module) signifie que toute la complexité des balises de construction, des packages de test, etc. . s'appliquent à eux, nous avons besoin d'un moyen de spécifier s'ils sont publics ou privés pour ce paquet, etc.

Ce que j'aime à ce sujet, c'est que des bibliothèques pourraient être écrites pour faciliter l'importation d'actifs. Par exemple. une bibliothèque avec un seul fichier Go qui intègre simplement une police, ou certaines icônes pourraient être publiées et je pourrais l'importer comme n'importe quel autre package go. À l'avenir, je pourrais obtenir une police d'icône simplement en l'important :

import "forkaweso.me/forkawesome/v2"

approche de paquet intégré

Bien que j'aime l'idée que tout cela soit un code Go explicite et normal, je déteste l'idée que ce serait un autre package magique qui ne peut pas être implémenté en dehors de la bibliothèque standard.

Un tel package serait-il défini dans le cadre de la spécification du langage ? Sinon, c'est un autre endroit où le code Go se briserait entre différentes implémentations, ce qui semble également médiocre. Je continuerais probablement à utiliser un outil externe pour éviter cette casse.

De plus, comme d'autres l'ont mentionné, le fait que cela soit fait au moment de la construction signifie que ce package ne peut prendre que des littéraux de chaîne ou des constantes comme arguments. Il n'y a actuellement aucun moyen de représenter cela dans le système de types, et je soupçonne que ce sera un point de confusion. Cela pourrait être résolu en introduisant quelque chose comme des fonctions constantes, mais maintenant nous parlons de changements de langage majeurs, ce qui en fait un non-démarreur. Je ne vois pas un bon moyen de résoudre ce problème autrement.

Hybride

J'aime l'idée d'une approche hybride. Au lieu de réutiliser les commentaires (qui finissent par être éparpillés un peu partout et, sur une note personnelle, se sentent juste dégoûtants), j'aimerais voir tous les actifs mis au même endroit, probablement le fichier go.mod comme les autres a dit:

module forkaweso.me/forkawesome/v2

go 1.15

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

Cela signifie que les actifs ne peuvent pas être inclus ou exclus par des balises de construction arbitraires ou dans des packages arbitraires (par exemple, le package _testing) sans créer un module séparé. Je pense que cette réduction de la complexité peut être souhaitable (il n'y a pas de balise de construction cachée dans une bibliothèque que vous essayez d'importer, et vous ne pouvez pas comprendre pourquoi vous n'avez pas le bon actif car l'importation de la bibliothèque aurait dû l'intégrer) , mais YMMV. Si cela est souhaitable, des commentaires de type pragma peuvent toujours être utilisés, sauf qu'ils ne génèrent pas de code et utilisent à la place la même approche que celle que je suis sur le point de décrire pour la version go.mod .

Contrairement à la proposition originale, cela ne générerait aucun code. Au lieu de cela, la fonctionnalité pour par exemple. la lecture de la section de données du fichier ELF (ou cependant, cela finit par être stocké sur le système d'exploitation que vous utilisez) serait ajoutée le cas échéant (par exemple, os ou debug/elf , etc.) et puis, éventuellement, un nouveau package serait créé qui se comporte exactement comme le package décrit dans l'OP, sauf qu'au lieu d'être magique et de faire l'intégration lui-même, il lit simplement les fichiers intégrés (ce qui signifie qu'il pourrait être implémenté en dehors de la bibliothèque standard si on le désire).

Cela permet de contourner des problèmes tels que la nécessité de restreindre le package magique pour n'autoriser que les littéraux de chaîne comme arguments, mais cela signifie qu'il est plus difficile de vérifier si les actifs intégrés sont réellement utilisés n'importe où ou finissent par être un poids mort. Cela évite également toute nouvelle dépendance entre les packages de bibliothèque standard, car le seul package qui doit importer quelque chose de supplémentaire est un nouveau package lui-même.

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

Comme vu ci-dessus, mettre les ressources dans le module peut toujours les étendre à ce module particulier si vous le souhaitez. L'API réelle et la façon dont vous sélectionnez un élément peuvent nécessiter un certain travail.

Encore une autre idée : au lieu d'ajouter un nouveau type de verbe embed dans go.mod , nous pourrions introduire un nouveau type de package, un package de données, qui est importé et utilisé dans go.mod dans le Manière habituelle. Voici un croquis d'homme de paille.

Si un package contient exactement un fichier .go , static.go , et que ce fichier ne contient que des commentaires et une clause de package, alors un package est un package de données. Lorsqu'il est importé, cmd/go remplit le package avec des fonctions exportées donnant accès aux fichiers qu'il contient, qui sont intégrés dans le binaire résultant.

S'il s'agit d'un package réel, cela signifierait que les règles internal s'appliqueraient et que nous pouvons avoir des contrôles d'accès sans ajouter à l'API.

Qu'en est-il alors de l'inclusion automatique de tous les fichiers et sous-dossiers non .go (en suivant les règles d'absence de code) dans le répertoire ?

Si un package contient exactement un fichier .go , static.go , et que ce fichier ne contient que des commentaires et une clause de package, alors un package est un package de données.

Cette vérification serait-elle effectuée avant l'application des balises de construction ? Si c'est le cas, cela semble être un autre cas particulier, qu'il faudrait peut-être éviter. Sinon, il est tout à fait possible qu'un package soit considéré comme un package Go standard pour certaines balises de construction et comme un package de données pour d'autres. Cela semble étrange, mais peut-être est-ce souhaitable ?

@flimzy
Cela permettrait en quelque sorte d'utiliser des fichiers intégrés avec une seule balise et de définir les mêmes fns/vars que le package généré et de servir les fichiers d'une autre manière (peut-être à distance ?) avec une autre balise.

Ce serait bien s'il y avait un indicateur de construction pour générer les fonctions wrapper, il suffit donc de remplir les blancs.

@josharian

Si un package contient exactement un fichier .go , static.go , et que ce fichier ne contient que des commentaires et une clause de package, alors un package est un package de données.

Je peux imaginer les packages de "données" comme ayant leur propre fonctionnalité spécifique à un domaine, telle qu'une recherche de code postal. L'approche que vous venez de proposer n'autoriserait rien d'autre que les données brutes, et annulerait ainsi les avantages de pouvoir emballer la logique avec les données.

Je peux imaginer les packages de "données" comme ayant leur propre fonctionnalité spécifique à un domaine, telle qu'une recherche de code postal.

Vous pouvez exposer des fonctionnalités dans my.pkg/postalcode et mettre des données dans my.pkg/postalcode/data (ou my.pkg/postalcode/internal/data).

Je vois l'intérêt de procéder comme vous le suggérez, mais cela soulève un tas de questions : comment fonctionne la rétrocompatibilité ? Comment marquer un paquet de données en tant que tel ? Que faites-vous si le package contient des fonctions qui entreraient en conflit avec celles que cmd/go ajouterait ? (Je ne dis pas que ceux-ci n'ont pas de réponses, juste qu'il est plus simple de ne pas avoir à y répondre.)

@josharian , veuillez considérer le commentaire de vérification de type ci-dessus (https://github.com/golang/go/issues/35950#issuecomment-561443566).

@bradfitz oui, il s'agirait d'un changement de langue et nécessiterait la prise en charge de go/types.

En fait, il existe un moyen de le faire sans que ce soit un changement de langue - exiger que static.go contienne des fonctions sans corps correspondant exactement à ce que cmd/go remplirait.

nécessite que static.go contienne des fonctions sans corps correspondant exactement à ce que cmd/go remplirait.

S'il génère des fonctions par fichier au lieu d'un catch all embed.File() , cela permettrait des contrôles d'exportation faciles par actif.

Ainsi, les éléments générés ressembleraient à :

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

Un article de blog que j'ai écrit sur les fichiers statiques il y a 4 mois. Voir la dernière phrase dans les conclusions :-)

@josharian

Vous pouvez exposer des fonctionnalités dans my.pkg/postalcode et mettre des données dans my.pkg/postalcode/data (ou my.pkg/postalcode/internal/data).

Cela – bien que peu élégant – pourrait répondre à mes préoccupations.

Comment fonctionne la rétrocompatibilité ?

Je ne vois pas en quoi les préoccupations de la Colombie-Britannique s'appliquent ici. Peux-tu élaborer?

Comment marquer un paquet de données en tant que tel ?

Avec l'instruction embed dans le go.mod ?

Peut-être que je ne suis pas ce que vous demandez.

Mais je vais le retourner; comment marquer un paquet avec uniquement des données en tant que telles ?

Que faites-vous si le package contient des fonctions qui entreraient en conflit avec celles que cmd/go ajouterait ?

1. En utilisant l'approche proposée, je ne pense pas que cmd/go ait besoin d'ajouter des fonctions.

2. Même si cmd/go a besoin d'ajouter des fonctions, j'imagine que le comportement des conflits dans un package _existant_ serait _non défini_.

   La proposition suppose que le développeur suit le principe de responsabilité unique et ne devrait donc créer qu'un package avec des données pour être un package centré sur les données et ne pas ajouter de données à un package centré sur la logique existant.

   Bien sûr, un développeur _pourrait_ ajouter à un package existant, auquel cas le comportement serait indéfini. IOW, si un développeur ignore l'idiome, il serait en territoire inconnu.

Je ne dis pas que ceux-ci n'ont pas de réponses, juste qu'il est plus simple de ne pas avoir à y répondre.

Sauf que je pense que les réponses sont simples. Au moins pour ceux que vous avez posés jusqu'à présent.

Je pense que toute solution qui ajoute des symboles ou des valeurs pour les symboles doit être étendue au package, et non au module. Parce que l'unité de compilation pour Go est package, pas module.

Cela laisse donc de côté toute utilisation de go.mod pour spécifier la liste des fichiers à importer.

@dolmen si le résultat final est dans son propre package, alors la portée elle-même serait un module.

@urandom Non, la portée est le ou les packages qui importent ce package généré. Mais de toute façon, je ne pense pas qu'un package généré complet soit dans le cadre de cette proposition.

@urandom Non, la portée est le ou les packages qui importent ce package généré. Mais de toute façon, je ne pense pas qu'un package généré complet soit dans le cadre de cette proposition.

quelle que soit la manière dont cette proposition serait implémentée, étant donné que divers packages de modules utiliseront le résultat final, il est logique que la définition de ce qui est intégré soit spécifiée au niveau du module. un précédent existe déjà dans l'écosystème Java, où les fichiers intégrés sont de portée de module et ajoutés à partir d'un répertoire magique.

de plus, go.mod présente le moyen le plus propre d'ajouter une telle fonctionnalité (pas de commentaires magiques, ni de répertoires magiques) sans casser les programmes existants.

Voici quelque chose qui n'a pas encore vu mentionné : l'API pour les outils de traitement des sources Go (compilateur, analyseurs statiques) est aussi importante que l'API d'exécution. Ce type d'API est une valeur fondamentale de Go qui aide à développer l'écosystème (comme go/ast / go/format et go mod edit ).

Cette API pourrait être utilisée par des outils de pré-processeur (en pas go:generate notamment) pour obtenir la liste des fichiers qui seront embarqués ou elle pourrait être utilisée pour générer la référence.

Dans le cas d'un package spécial, je ne vois rien à changer dans l'analyse go.mod ( go mod tools) ou l'analyseur go/ast .

@dolmen

_"Je pense que toute solution qui ajoute des symboles ou des valeurs pour les symboles doit être étendue au package, pas au module. Parce que l'unité de compilation pour Go est le package, pas le module. Cela exclut donc toute utilisation de go.mod pour spécifier la liste des fichiers à importer."_

Qu'est-ce qu'un module ? Les modules sont _" une collection de packages Go associés qui sont versionnés ensemble en une seule unité ."_ Ainsi, un module peut consister en un seul package, et un seul package peut être l'intégralité d'un module.

En tant que tel, go.mod est le bon endroit pour spécifier la liste des fichiers à importer en supposant que l'équipe Go adopte go.mod sur les commentaires spéciaux et les packages magiques. C'est à moins que et jusqu'à ce que l'équipe Go décide d'ajouter un fichier go.pkg .

De plus, si l'équipe Go acceptait go.mod comme emplacement pour spécifier les fichiers d'intégration, toute personne souhaitant intégrer des fichiers devrait fournir un go.mod avec les instructions embed , et le package qui est représenté par le répertoire dans lequel réside le fichier go.mod serait le package qui contient les fichiers intégrés.

Mais si ce n'est pas ce que le développeur veut, il doit créer un autre fichier go.mod et le mettre dans le répertoire du package qu'il souhaite contenir ses fichiers intégrés.

Y a-t-il un scénario légitime que vous envisagez où ces contraintes ne seraient pas réalisables ?

@mikeschinkel , un module est une collection de packages _related_. Cependant, il est possible (et raisonnable !) d'utiliser un package d'un module sans extraire les dépendances transitives (et les données !) d'autres packages au sein de ce module.

Les fichiers de données sont généralement des dépendances par package, et non par module, de sorte que les informations sur la façon de localiser ces dépendances doivent être colocalisées avec le package, et non stockées en tant que métadonnées distinctes au niveau du module.

@bcmills

Il semble que l'on puisse remplacer « fichiers de données » dans votre message par « modules » et cela restera vrai.
Il est assez courant d'avoir des modules spécifiques en tant que dépendances pour vos propres packages spécifiques.
Pourtant, nous les mettons tous dans le go.mod.

@urandom , tous les packages des modules indiqués dans le fichier go.mod ne sont pas liés dans le binaire final. (Mettre une dépendance dans le fichier go.mod n'est _pas_ équivalent à lier cette dépendance au programme.)

Méta-point

Il est clair que c'est quelque chose qui intéresse beaucoup de gens, et le commentaire original de Brad en haut était moins une proposition finie qu'un croquis initial / un point de départ / un appel à l'action. Je pense qu'il serait logique à ce stade de mettre fin à cette discussion spécifique, de faire collaborer Brad et peut-être quelques autres personnes sur un document de conception détaillé, puis de commencer un nouveau numéro pour une discussion sur ce document spécifique (à rédiger). . Il semble que cela aiderait à concentrer ce qui est devenu une conversation un peu tentaculaire.

Les pensées?

Je ne suis pas sûr d'être d'accord avec la fermeture de celui-ci, mais nous pouvons le maintenir en proposition jusqu'à ce qu'il y ait un document de conception et verrouiller les commentaires pendant un moment. (Presque tous les commentaires sont redondants à ce stade, car il y a trop de commentaires pour que les gens puissent les lire pour voir si leur commentaire est redondant...)

Peut-être que lorsqu'il y a un document de conception, celui-ci peut être fermé.

Ou fermez celui-ci et rouvrez #3035 (avec les commentaires gelés) afin qu'au moins un problème ouvert le suive.

Désolé de le faire juste après avoir parlé de la fermeture, mais la discussion étroite a commencé juste après le commentaire de

"_Cependant, il est possible (et raisonnable !) d'utiliser un package d'un module sans extraire les dépendances transitives (et les données !) d'autres packages au sein de ce module."_

Oui, c'est clairement _possible._ Mais comme pour toute bonne pratique, une bonne pratique pour les packages de données pourrait être de créer un seul package pour un module, ce qui résout votre problème. Si cela signifie un go.mod à la racine et un autre go.mod dans le sous-répertoire contenant le paquet de données, qu'il en soit ainsi.

Je suppose que je préconise que vous ne faites pas du parfait l'ennemi du bien ici, où le bien ici est identifié comme go.mod étant un endroit parfait pour spécifier des fichiers d'intégration étant donné que, par leur nature, ils sont une liste des composants d'un module.

Désolé, mais les packages sont le concept fondamental de Go, pas les modules.
Les modules sont simplement des groupes de packages qui sont versionnés en tant qu'unité.
Les modules n'apportent pas de sémantique supplémentaire au-delà de celles des packages individuels.
Cela fait partie de leur simplicité.
Tout ce que nous faisons ici doit être lié à des packages, pas à des modules.

Où que cela se passe et quelle que soit la manière dont cela est fait, il devrait y avoir un moyen d'obtenir une liste de tous les actifs qui seront intégrés à l'aide de la liste go (pas seulement les modèles utilisés).

Mettre en attente jusqu'à ce que Brad et d'autres élaborent un document de conception formel.

Le blocage de certains fichiers ne devrait pas être trop difficile, surtout si vous utilisez un répertoire static ou embed . Les liens symboliques peuvent compliquer un peu cela, mais vous pouvez simplement l'empêcher d'intégrer quoi que ce soit en dehors du module actuel ou, si vous êtes sur GOPATH, en dehors du package contenant le répertoire.

Je ne suis pas particulièrement fan d'un commentaire qui compile en code, mais je trouve également un peu étrange le pseudo-paquet qui affecte la compilation. Si l'approche par répertoire n'est pas utilisée, il serait peut-être plus logique d'avoir une sorte embed déclaration de niveau supérieur import , mais ne prendrait en charge que les chemins locaux et nécessiterait un nom pour lui être attribué. Par exemple,

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))
}

Edit : Tu m'as devancé, @jayconrod.

Ceci est propre et lisible, mais je ne suis pas sûr que l'équipe de go veuille introduire un nouveau mot-clé

L'idée, si je me souviens bien, était d'avoir simplement un nom de répertoire spécial comme "static" contenant les données statiques et de les rendre automatiquement disponibles via une API, sans annotations nécessaires.

Utiliser static comme nom de répertoire spécial est un peu déroutant et je préfèrerais utiliser assets .
Une autre idée que je n'ai pas vue dans le fil est de permettre l'importation de assets tant que package, par exemple import "example.com/internal/assets" . L'API exposée a toujours besoin d'une conception, mais au moins elle a l'air plus propre que les commentaires spéciaux ou les nouveaux packages de style runtime/files .

Une autre idée que je n'ai pas vue dans le fil est d'autoriser l'importation d'actifs en tant que package

Cela a été proposé ici : https://github.com/golang/go/issues/35950#issuecomment -562966654

Une complication est que pour permettre la vérification des types, vous devez soit changer de langue, soit fournir des fonctions sans corps à remplir par cmd/go .

C'est une idée similaire, mais la conception static.go permet de transformer un chemin d'importation arbitraire en paquet de données, tandis que le répertoire assets fonctionne plutôt comme testdata , internal ou vendor en termes d'être "spécial". L'une des exigences possibles de assets est de ne contenir aucun paquet Go (ou de n'autoriser que les docs), c'est-à-dire pour une rétrocompatibilité implicite.

Cela pourrait également être combiné avec l'API runtime/files -thingy pour obtenir les fichiers. C'est-à-dire en utilisant des import bruts pour incorporer des arborescences de répertoires avec des fichiers, puis en utilisant un package d'exécution pour y accéder. Peut-être même os.Open , mais il est peu probable que cela soit accepté.

Le shurcooL/vfsgen ensemble shurcooL/httpgzip a une fonctionnalité intéressante où le contenu peut être servi sans décompression.

par exemple

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

Une fonctionnalité similaire est proposée pour le C++ : std::embed :

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

Il peut être utile comme source d'inspiration pour un design, et pour collecter des cas d'utilisation possibles.

Je suis un peu en retard pour la fête, mais j'ai eu une idée. Au lieu de commentaires spéciaux, un répertoire spécial fixe (statique) ou l'approche apparemment sans aucun de l'extension de go.mod : que diriez-vous d'un nouveau fichier manifeste par package : go.res

• Contient une liste de fichiers. Pas de chemins ni de globs, juste des noms dans le répertoire du package actuel. Générez-le à partir d'un glob avant de vous engager si vous en avez besoin.
  
  
  
  • __Edit__ il pourrait avoir besoin d'une seule ligne package mypackagename en haut, comme un fichier go l'aurait fait. Alternativement, vous pouvez inclure le nom du package dans le nom de fichier (par exemple mypackagename.go.res). Personnellement, j'aime mieux la ligne d'en-tête package .
  
  
• Un nouveau package de base appelé « ressource » ou peut-être « io/resource ». Possède au moins une fonction : func Read(name string) (io.Reader, bool) pour lire les ressources intégrées dans le package actuel.
  
  
  
  • __Edit__ Pas sûr que les packages principaux fonctionnent de cette façon. Peut-être qu'il s'agit d'une fonction privée de package générée (par exemple, func readresource(name string) (io.Reader, bool) )
  
  
• Si vous voulez des ressources dans un sous-répertoire, faites du sous-répertoire un package en ajoutant un fichier go.res et au moins un fichier .go . Le fichier go exporte votre propre API publique pour accéder aux ressources du package de sous-répertoire. Le fichier go et l'API exportée sont nécessaires, car les ressources d'autres packages ne sont pas automatiquement exportées (par conception). Vous pouvez également personnaliser la façon dont ils sont exportés de cette façon.
  
  
  
  • __Edit__ alternativement, si vous avez besoin d'une structure de répertoire et/ou d'une compression, utilisez une ressource tar. Cela permet des choses comme les bundles webpack, qui nécessitent déjà une compilation (et pourraient bénéficier de la pré-compression). Les amener un peu plus loin vers un goudron est simple.
  
  
• __Modifier__ Besoin d'un manifeste ? Incluez simplement le fichier go.res lui-même en tant que ressource. Nous n'avons même pas besoin de créer une fonction listresources.

Extrêmement simple. Une nouvelle fonction. Un nouveau fichier. Pas de chemins. Pas de compression. Pas de nouvelle syntaxe. Pas de magie. Extensible. Accès en lecture seule via le lecteur (mais ouvert à d'autres modèles d'accès à l'avenir). Possibilité quasi nulle de casser les packages existants. Le package reste la construction de base dans go.

__Edit__ Après une recherche github language:go filename:go.res extension:res , il semble que go.res serait un nom de fichier assez sûr à utiliser. Il n'y a pas de correspondances dans les repos go, et seulement quelques-uns dans les repos non go.

J'aime l'idée de @chris.ackermanm. Mais je préférerais une combinaison :

Un fichier go.res spécifiant l'espace de noms dans un répertoire.

Cela permet de

• multiple comprend tant que l'espace de noms diffère
• ne pas connaître les fichiers avant et devoir générer une liste

Ce dernier devrait s'attaquer à la sortie de webpack et autres qui peuvent changer la mise en page en raison des mises à jour, des différentes options, tout ce à quoi vous pouvez penser.

En ce qui concerne la compression : je pense que c'est plus une fonctionnalité en termes de non-explosion des tailles binaires et devrait être transparente pour le code d'utilisation.

Plus tard, vous pourrez autoriser des réécritures telles que

filename => stored-as.png

Juste mon 2¢

@sascha-andres On dirait de l'ultra simplicité et zéro magie est le ton de ce fil. Voir les modifications que j'ai apportées à mon commentaire concernant vos suggestions.

Je n'aime pas la cartographie. Ce n'est pas nécessaire. C'est possible en exposant de toute façon votre propre fonction de lecture à partir d'un package séparé, et maintenant nous avons besoin d'une nouvelle syntaxe de fichier, ou de quelque chose de plus complexe que le fichier par ligne.

salut

Cette proposition est géniale !

Et j'ai mon approche pour intégrer des actifs. pas besoin d'introduire d'autres outils que GNU bintools. C'est un peu sale, mais ça marche bien pour moi pour le moment. Je veux juste le partager et voir si cela aide.

mon approche consiste simplement à intégrer mes actifs (compressés avec tar&gz) dans une section elf/pe32 avec objcopy, et à les lire via les packages debug/elf et debug/pe32 avec zip si nécessaire. tout ce dont je dois me souvenir, c'est de ne toucher à aucune section existante. tous les actifs sont immuables puis le code lit le contenu et le traite en mémoire.

Je suis assez inexpérimenté en conception de langage ou en conception de compilateur. donc j'utiliserais simplement l'approche décrite ci-dessus et utiliserais .goassets ou quelque chose comme ça comme nom de section. et rendre la compression facultative.

mon approche consiste simplement à intégrer mes actifs (compressés avec tar&gz) dans une section elf/pe32 avec objcopy, et à les lire via les packages debug/elf et debug/pe32 avec zip si nécessaire. tout ce dont je dois me souvenir, c'est de ne toucher à aucune section existante. tous les actifs sont immuables puis le code lit le contenu et le traite en mémoire.

On dirait que ça marche sur elf / pe32 mais qu'en est-il de mach-o / plan9 ?

Un autre problème est qu'il repose sur l'ouverture d'un descripteur de fichier sur l'exécutable, si l'exécutable a été écrasé/mis à jour/supprimé, cela renverra des données différentes, sans savoir s'il s'agit d'un problème légitime ou d'une fonctionnalité inattendue.

J'ai essayé moi-même (en utilisant debug/macho ), mais je ne vois pas comment faire fonctionner cette multiplateforme, je construis sur macOS et les binutils GNU installés semblent juste corrompre le mach-o-x86-64 (cela pourrait simplement être mon manque de compréhension de la structure mach-o et trop long puisque j'ai même regardé objcopy ).

Un autre problème est qu'il repose sur l'ouverture d'un descripteur de fichier sur l'exécutable

Je suis presque sûr que le chargeur de programme chargera (ou pourrait) charger la section des ressources en mémoire, il n'est donc pas nécessaire d'utiliser des packages de débogage. Bien que l'accès aux données nécessiterait beaucoup plus de bricolage avec les fichiers objets que cela n'en vaut la peine.

Pourquoi ne pas suivre ce qui fonctionne -- par exemple comment Java le fait. J'aurais besoin que les choses soient un gros go-ish, mais quelque chose dans les lignes:

• créer un fichier go.res ou modifier go.mod pour pointer vers le répertoire où se trouvent les ressources
• tous les fichiers de ce répertoire sont automatiquement inclus, aucune exception par le compilateur dans l'exécutable final
• language fournit une API de type chemin pour accéder à ces ressources

La compression, etc. doit être en dehors de la portée de ce regroupement de ressources et peut aller jusqu'à n'importe quel script // go:generate si nécessaire.

Quelqu'un a-t-il regardé markbates/pkger ? C'est une solution assez simple d'utiliser go.mod comme répertoire de travail actuel. En supposant qu'un index.html soit intégré, son ouverture serait pkger.Open("/index.html") . Je pense que c'est une meilleure idée que de coder en dur un répertoire static/ dans le projet.

Il convient également de mentionner que Go n'a pas d'exigences de structure significatives pour un projet d'après ce que j'ai pu voir. go.mod n'est qu'un fichier et peu de gens utilisent vendor/ . Personnellement, je ne pense pas qu'un répertoire static/ serait bon.

Comme nous avons déjà un moyen d'injecter des données (bien que limitées) dans une version via le drapeau de lien ldflags existant -X importpath.name=value , ce chemin de code pourrait-il être ajusté pour accepter -X importpath.name=@filename à injecter données arbitraires externes ?

Je me rends compte que cela ne couvre pas tous les objectifs énoncés du numéro d'origine, mais en tant qu'extension de la fonctionnalité -X existante, cela semble-t-il un pas en avant raisonnable ?

(Et si cela fonctionne, alors l'extension de la syntaxe go.mod comme moyen plus ordonné de spécifier les valeurs ldflags -X est une prochaine étape raisonnable ?)

C'est une idée très intéressante, mais je m'inquiète des implications pour la sécurité.

C'est assez courant de faire -X 'pkg.BuildVersion=$(git rev-parse HEAD)' , mais nous ne voudrions pas laisser go.mod exécuter des commandes arbitraires, n'est-ce pas ? (Je suppose que go generate le fait, mais ce n'est pas quelque chose que vous exécutez généralement pour les packages OSS téléchargés.) Si go.mod ne peut pas gérer cela, il manque un cas d'utilisation majeur, donc les ldflags seraient toujours très courants.

Ensuite, il y a l'autre problème de s'assurer que @filename n'est pas un lien symbolique vers /etc/passwd ou autre.

L'utilisation de l'éditeur de liens empêche la prise en charge de WASM et éventuellement d'autres cibles qui n'utilisent pas d'éditeur de liens.

Sur la base de la discussion ici, @bradfitz et moi avons élaboré une conception qui se situe quelque part au milieu des deux approches considérées ci-dessus, en prenant ce qui semble être le meilleur de chacune. J'ai publié un projet de document de conception, une vidéo et un code (liens ci-dessous). Au lieu de commentaires sur ce problème, veuillez utiliser les questions-réponses de Reddit pour des commentaires sur ce projet de conception spécifique - Reddit gère les discussions et les met à l'échelle mieux que GitHub. Merci!

Vidéo : https://golang.org/s/draft-embed-video
Conception : https://golang.org/s/draft-embed-design
Questions et réponses : https://golang.org/s/draft-embed-reddit
Code : https://golang.org/s/draft-embed-code

@rsc À mon avis, la proposition go:embed est inférieure à l'exécution de code Go _universel_ en bac à sable au moment de la compilation, ce qui inclurait la lecture des fichiers et la transformation des données lues dans un _format optimal_ le mieux adapté à la consommation au moment de l'exécution.

@atomsymbol Cela ressemble à quelque chose qui sort du cadre de ce problème.

@atomsymbol Cela ressemble à quelque chose qui sort du cadre de ce problème.

Je suis au courant de ça.

J'ai lu la proposition et scanné le code, mais je n'ai pas trouvé de réponse à cette question : ce schéma d'intégration contiendra-t-il des informations sur le fichier sur le disque (~os.Stat) ? Ou ces horodatages seront-ils réinitialisés en fonction de l'heure de construction ? Quoi qu'il en soit, ce sont des informations utiles qui sont utilisées à divers endroits, par exemple, nous pouvons envoyer un 304 pour les actifs inchangés en fonction de cela.

Merci!

Edit: trouvé dans le fil reddit.

L'heure de modification pour tous les fichiers intégrés est l'heure zéro, pour exactement les problèmes de reproductibilité que vous avez énumérés. (Les modules n'enregistrent même pas les heures de modification, encore une fois pour la même raison.)

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

Quoi qu'il en soit, ce sont des informations utiles qui sont utilisées à divers endroits, par exemple, nous pouvons envoyer un 304 pour les actifs inchangés en fonction de cela.

Un en-tête ETag basé sur le hachage des données du fichier résoudrait ce problème sans avoir à connaître quoi que ce soit sur les dates. Mais cela devrait être connu par http.HandlerFS ou quelque chose pour pouvoir fonctionner et pour ne pas gaspiller de ressources, cela ne devrait être fait qu'une seule fois par fichier.

Mais cela devrait être connu par http.HandlerFS ou quelque chose pour pouvoir fonctionner et pour ne pas gaspiller de ressources, cela ne devrait être fait qu'une seule fois par fichier.

Comment http.HandlerFS saurait-il que le fichier fs.FS était immuable ? Devrait-il y avoir une interface optionnelle IsImmutable() bool ?

Comment http.HandlerFS saurait-il que le fichier fs.FS était immuable ? Devrait-il y avoir une interface optionnelle IsImmutable() bool ?

Je ne veux pas entrer dans les détails de l'implémentation car je ne suis pas le concepteur de ces choses, mais http.HandlerFS pourrait vérifier s'il s'agit d'un type embed.FS et agir sur cela comme un cas particulier, je ne pense pas que quiconque veuille le faire développez l'API FS dès maintenant. Il pourrait également y avoir un argument d'option à HandlerFS spécifiquement pour lui dire de traiter un système de fichiers comme immuable. De plus, si cela est fait au démarrage de l'application et que tous les ctime/mtime ont une valeur nulle, handlerFS pourrait utiliser ces informations pour "savoir" que le fichier n'a pas changé, mais il existe également des systèmes de fichiers qui pourraient ne pas avoir mtime ou le désactiver. peut-être aussi des problèmes là-bas.

Je ne regardais pas les commentaires sur cette question.

@atomsymbol bon retour ! C'est super de te revoir commenter ici.
Je suis d'accord sur le principe que si nous avions du sandboxing, beaucoup de choses seraient plus faciles.
D'un autre côté, beaucoup de choses peuvent être plus difficiles - les builds peuvent ne jamais se terminer.
Quoi qu'il en soit, nous n'avons certainement pas ce genre de sandbox aujourd'hui. :-)

@kokes je ne suis pas sûr des détails,
mais nous veillerons à ce que la diffusion d'un embed.Files sur HTTP obtienne les ETags correctement par défaut.

J'ai déposé le numéro 41191 pour avoir accepté le projet de conception publié en juillet.
Je vais clore ce sujet comme remplacé par celui-là.
Merci pour la grande discussion préliminaire ici.