# File organization for sharing ArcGIS python code

What is the best organizational structure for sharing ArcGIS python code and geoprocessing tools? Or even, are sharing code and sharing tools separate questions?

Esri has a Methods for distributing tools structure, published for Arcgis 9.3 and 10.0:

However in other places people are saying things like Also do avoid distributing your code the way its done in Arc Scripts or Code Galleries in favour of the native python Distutils. Esri doesn't seem to have a corresponding distributing tools article for 10.1 (ref), lending some weight to the counter-argument.

What says GIS.se?

Update: though perhaps too late, but the nub of this question is more about best practices for file and folder structure before the tools-used-for-sharing (arcgis online, google drive, dropbox, github, bitbucket, etc.) come into play.

Update2: and will no-one speak up for the apparently orphan distutils approach?

• Did you ever come up with a workable solution for this? – traggatmot Feb 3 '17 at 15:46
• @traggatmot no I haven't. Today I would inspect Esri's Github site for the python-with-toolboxes-project with the most stars and/or most active contribution history (emphasis on the 2nd since this Q is about sharing and re-use) – matt wilkie Feb 6 '17 at 22:08

At 10.1 and 10.2 the Toolshare Folders that you illustrated seem no longer to be documented.

I suspect this is because the current recommendation would be to use Geoprocessing Packages rather than Toolshare Folders:

Geoprocessing packages are created from one or more results in the Results window. All the data and tools used to create the result are included in the package. You can add additional files to the package, such as text documents, slide shows, and compressed ZIP files. Your colleague unpacks the package to immediately begin using its contents.

In terms of organizational best practice the way I store toolboxes and any Python code they use is in the same folder structure that can still be used to assist distributing them i.e. Toolshare Folder structure.

• ...which I suppose means the answer to "what is the organizational structure" may be discovered by manually unzipping a geoprocessing package file and examining it's innards. – matt wilkie Nov 13 '12 at 22:07
• I have not tried renaming to *.zip and unzipping a *.gpk but my understanding is that you could do that. I suspect it will look an awful lot like a toolshare folder. – PolyGeo Nov 14 '12 at 6:33

I have been using Google Drive to share Python scripts and script tools between colleagues. All of the scripts are stored in a shared folder along with an ArcGIS toolbox, which contains all of the linked script tools (and models). There are several benefits to this approach: 1) Everyone works off the same script versions, 2) You can set write or read-only privileges, and 3) Collaboration, for example, across different workplaces, universities and countries is much easier with Google Drive than than trying to set user access on a server you may or may not administer.

• +1, and the same could be said for Dropbox – om_henners Oct 17 '12 at 22:47
• So you store all of your scripts & toolboxes at the same folder level, correct? – RyanKDalton Oct 17 '12 at 22:54
• @RyanDalton For simplicity, I usually store folders one deep at the same level as toolboxes. Although, Gdrive supports complicated file structure too. – Aaron Oct 17 '12 at 23:03
• Anyone who finds this workflow appealing should definitely take a look at the version control software Git and its popular repository-sharing website, GitHub. It gives you all of the above - a master script, defined privileges, and broad accessibility - with the ability to track all the changes made to the script (including date and author), experiment with new features while preserving the production version, manage multiple editing the same files simultaneously, etc. It's more complicated to use, but I've found it to be immensely useful. – Matt Parker Oct 22 '12 at 22:37
• Google Drive, Dropbox, Git + Github, Mercurial + Bitbucket, and friends are all great routes for sharing files and code, but that's not the nub of this question. I'm after best practices for file and folder structure before the tools-used-for-sharing come into play. – matt wilkie Nov 13 '12 at 21:59

Esri's ArcGIS Pro doc Extending geoprocessing through Python modules shows how to structure a project that is Distutils friendly, including building Windows and Linux binary installers.

(Note: this is for sharing scripts and tools, it's not a good model for sharing scripts and maps and data as a single package.)

Source project layout:

Becomes this on end user's system, under C:\Path\to\ArcGIS\Desktop\python

They don't mention pip but from studying the examples I don't see why it wouldn't work. Ex: for collaborative editing and/or a toolset that changes often, install using pip install --editable X:\path\to\src, pip install --editable http://github.com/project/path/to/master