Organisation des fichiers pour partager le code python ArcGIS

13

Quelle est la meilleure structure organisationnelle pour partager du code python ArcGIS et des outils de géotraitement? Ou même, le partage de code et les outils de partage sont-ils des questions distinctes?

Esri dispose d'une structure Méthodes de distribution d'outils , publiée pour Arcgis 9.3 et 10.0:

exemple de structure de dossier de distribution d'outils

Cependant, dans d' autres endroits, les gens disent des choses comme Also do avoid distributing your code the way its done in Arc Scripts or Code Galleriesen faveur des Distutils en python natif . Esri ne semble pas avoir un article correspondant sur les outils de distribution pour 10.1 ( ref ), ce qui donne du poids au contre-argument.

Que dit GIS.se?

Mise à jour: mais peut-être trop tard, mais le nœud de cette question concerne davantage les meilleures pratiques pour la structure des fichiers et des dossiers avant que les outils utilisés pour le partage (arcgis en ligne, google drive, dropbox, github, bitbucket, etc.) entrent en jouer.

Update2: et personne ne parlera de l'approche des distutils apparemment orphelins?

Matt Wilkie
la source
Avez-vous déjà trouvé une solution viable pour cela?
traggatmot
@traggatmot non, je ne l'ai pas fait. Aujourd'hui , j'inspecterais le site Github d'Esri pour le projet python-avec-boîtes à outils avec le plus d'étoiles et / ou l'historique de contribution le plus actif (accent sur le 2e puisque ce Q concerne le partage et la réutilisation)
matt wilkie

Réponses:

10

Aux versions 10.1 et 10.2, les dossiers Toolshare que vous avez illustrés ne semblent plus être documentés.

Je soupçonne que c'est parce que la recommandation actuelle serait d'utiliser des packages de géotraitement plutôt que des dossiers Toolshare:

Les packages de géotraitement sont créés à partir d'un ou plusieurs résultats dans la fenêtre Résultats. Toutes les données et les outils utilisés pour créer le résultat sont inclus dans le package. Vous pouvez ajouter des fichiers supplémentaires au package, tels que des documents texte, des diaporamas et des fichiers ZIP compressés. Votre collègue décompresse le package pour commencer immédiatement à utiliser son contenu.

En termes de meilleures pratiques organisationnelles, la façon dont je stocke les boîtes à outils et tout code Python qu'elles utilisent est dans la même structure de dossiers qui peut toujours être utilisée pour aider à les distribuer, c'est-à-dire la structure de dossier Toolshare.

PolyGeo
la source
... ce qui, je suppose, signifie que la réponse à "quelle est la structure organisationnelle" peut être découverte en décompressant manuellement un fichier de package de géotraitement et en examinant ses entrailles.
matt wilkie
Je n'ai pas essayé de renommer * .zip et de décompresser un * .gpk mais je crois que vous pouvez le faire. Je pense qu'il ressemblera énormément à un dossier de partage d'outils.
PolyGeo
5

J'utilise Google Drive pour partager des scripts Python et des outils de script entre collègues. Tous les scripts sont stockés dans un dossier partagé avec une boîte à outils ArcGIS, qui contient tous les outils de script liés (et modèles). Cette approche présente plusieurs avantages: 1) Tout le monde travaille avec les mêmes versions de script, 2) Vous pouvez définir des privilèges d'écriture ou de lecture seule, et 3) La collaboration, par exemple, entre différents lieux de travail, universités et pays est beaucoup plus facile avec Google Drive que d'essayer de définir l'accès utilisateur sur un serveur que vous pouvez ou non administrer.

Aaron
la source
1
+1, et la même chose pourrait être dite pour Dropbox
om_henners
Vous stockez donc tous vos scripts et boîtes à outils au même niveau de dossier, n'est-ce pas?
RyanKDalton
@RyanDalton Pour plus de simplicité, je stocke généralement les dossiers un profondément au même niveau que les boîtes à outils. Cependant, Gdrive prend également en charge la structure de fichiers compliquée.
Aaron
2
Quiconque trouve ce flux de travail attrayant devrait certainement jeter un œil au logiciel de contrôle de version Git et à son site Web de partage de référentiel populaire, GitHub. Il vous offre tout ce qui précède - un script principal, des privilèges définis et une large accessibilité - avec la possibilité de suivre toutes les modifications apportées au script (y compris la date et l'auteur), d'expérimenter de nouvelles fonctionnalités tout en préservant la version de production, de gérer plusieurs éditer les mêmes fichiers simultanément, etc. C'est plus compliqué à utiliser, mais je l'ai trouvé extrêmement utile.
Matt Parker
Google Drive, Dropbox, Git + Github, Mercurial + Bitbucket et amis sont tous d'excellents itinéraires pour partager des fichiers et du code, mais ce n'est pas le nœud de cette question. Je recherche les meilleures pratiques pour la structure des fichiers et des dossiers avant que les outils utilisés pour le partage n'entrent en jeu.
matt wilkie
1

ArcGIS Pro doc d'Esri L' extension du géotraitement à travers des modules Python montre comment structurer un projet convivial Distutils, y compris la construction d'installateurs binaires Windows et Linux.

(Remarque: il s'agit du partage de scripts et d'outils, ce n'est pas un bon modèle pour partager des scripts, des cartes et des données en tant que package unique.)

Disposition du projet source:

Arbre Src

Devient ceci sur le système de l'utilisateur final, sous C:\Path\to\ArcGIS\Desktop\python

Arborescence du dossier de destination

Ils ne mentionnent pas pip mais en étudiant les exemples, je ne vois pas pourquoi cela ne fonctionnerait pas. Ex: pour l'édition collaborative et / ou un ensemble d'outils qui change souvent, installez en utilisant pip install --editable X:\path\to\src,pip install --editable http://github.com/project/path/to/master

Matt Wilkie
la source