Pecan: Rendre `data.atmosphere` (plus) autonome
Je propose que PEcAn.data.atmosphere soit un outil général de téléchargement et de traitement des données météorologiques (y compris le remplissage des lacunes, le formatage au standard PEcAn, etc.), _mais_ ne fournisse pas de fonctions spécifiques au workflow PEcAn. si nous pouvons faire en sorte que data.atmosphere soit autonome, cela facilitera l'installation et le test _et_ rendra les gens plus enclins à l'utiliser en dehors du flux de travail PEcAn standard (qui est sa propre forme de test).
Les dépendances PEcAn actuelles dans data.atmosphere sont PEcAn.DB et PEcAn.remote (et PEcAn.logger , mais c'est minuscule et change rarement, donc je ne l'inclus pas). PEcAn.DB est principalement utilisé dans met.process et les assistants associés. Je propose de déplacer met.process et ses amis vers PEcAn.workflow , ce qui devrait éliminer la dépendance à l'égard de PEcAn.DB et le besoin d'une base de données.
PEcAn.remote n'est utilisé que pour ses fqdn() pour déterminer le nom d'hôte de la machine actuelle. Je vous propose soit : (1) Créer une copie interne de fqdn() qui réside dans data.atmosphere et qui n'est pas exportée (c'est une petite fonction peu susceptible de changer à l'avenir, donc je pense que c'est bien vaut la peine d'éliminer une dépendance volumineuse, non-CRAN) ; ou (2) définir les informations host pour les téléchargements à distance en dehors des fonctions download.* (par exemple, en faire un argument facultatif de ces fonctions, ou simplement modifier la sortie data.frame en dehors des fonctions download.* ).
Les pensées?
ashiklom
Tous les 9 commentaires
Ça me semble être un bon plan.
mdietze
le 28 déc. 2019
Je soutiens pleinement cela et je peux essayer de fournir du soutien/de l'aide si nécessaire. FWIW, j'utilise déjà la plupart des fonctions data.atmosphere en dehors de PEcAn (ce qui m'amène à commenter les fonctions que vous mentionnez), il me sera donc plus facile de maintenir les fonctions principales de PEcAn à jour avec mon débogage si cela se produit.
crollinson
le 6 janv. 2020
Ce numéro est périmé car il a été ouvert 365 jours sans activité.
![github-actions[bot] picture](https://avatars.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
le 6 janv. 2021
@ashiklom puis-je travailler sur ce problème ?
moki1202
le 1 avr. 2021
@moki1202 Étant donné que data.atmosphere est très étroitement lié au flux de travail PEcAn global, je vous suggère fortement de vous configurer pour exécuter le flux de travail avec votre version du code en premier. Ensuite, pendant que vous travaillez sur ce problème, vous pouvez exécuter des workflows locaux et vous assurer que tout fonctionne toujours avant de soumettre la demande d'extraction.
ashiklom
le 6 avr. 2021
@ashiklom pour supprimer la dépendance à PEcAn.remote::fqdn() , je peux simplement déplacer le fichier base\remote\R\fqdn vers modulesdata.atmosphere et effectuer les ajustements appropriés dans le fichier de description, n'est-ce pas ?
moki1202
le 7 avr. 2021
Je copierais, pas déplacerais, de sorte que l'autre code ne soit pas affecté.
ashiklom
le 7 avr. 2021
@ashiklom vient de remarquer que ce problème n'aura pas besoin de beaucoup de travail une fois les packages téléchargés sur CRAN, n'est-ce pas ?
moki1202
le 14 avr. 2021
Peut-être. Mais « une fois que les packages sont téléchargés sur CRAN » fait référence à ce qui est probablement très long dans le futur ; éventuellement, jamais, selon le déroulement de cette tâche. Donc je ne compterais pas forcément dessus.
À mon avis, le séquençage _opposé_ est plus logique --- c'est-à-dire rendre ce package (et d'autres modules PEcAn) plus indépendants les uns des autres, _puis_ les télécharger un par un sur CRAN.
ashiklom
le 15 avr. 2021
Questions connexes
serbinsh
·
38Commentaires
serbinsh
·
12Commentaires
serbinsh
·
27Commentaires
tonygardella
·
11Commentaires
serbinsh
·
30Commentaires