AutoLISP, Dynamo und Python im Team verteilen und über Fassungswechsel hinweg pflegen

Der Ablageort ist die halbe Miete, und der Hersteller sagt euch, wie er aussehen soll

AutoCAD entscheidet über zwei Einstellungen, ob ausführbare Dateien geladen werden. Die eine ist eine Liste vertrauenswürdiger Ordner, die andere eine Systemvariable, die festlegt, wie streng damit umgegangen wird. Ab Werk steht die strenge Variante mit Warnung: Dateien aus vertrauenswürdigen Ordnern werden geladen, bei allen anderen erscheint eine Warnung. Der Administrator kann diese Einstellung festsetzen, und es gibt eine Stufe, bei der Dateien außerhalb der vertrauenswürdigen Ordner gar nicht mehr geladen werden.

Betroffen ist deutlich mehr, als die meisten vermuten. Autodesk nennt dazu ausdrücklich die Dateitypen der ObjectARX-Familie, die AutoLISP-Formate einschließlich der übersetzten und der Menüdateien, Skriptdateien von Netzwerkpfaden, .NET-Erweiterungen, VBA-Makros, JavaScript und DLL-Dateien. Wer also glaubt, das Thema betreffe nur zugekaufte Zusatzmodule, übersieht, dass die eigene kleine Routine unter dieselbe Regel fällt.

Die Empfehlung des Herstellers zum Zuschnitt der Ordner ist deutlich: eindeutige, schreibgeschützte Ordner, in denen die freigegebenen Anwendungen liegen, und möglichst geringe Rechte für alle übrigen Rollen. Ein Eintrag darf mit einer besonderen Endung auch alle Unterordner einschließen, was praktisch ist und den Kreis gleichzeitig weit macht. Die Programmverzeichnisse selbst gelten ohnehin als vertrauenswürdig. Für die Startsammlung gilt seit den Fassungen ab 2014 zusätzlich, dass dort eingetragene Anwendungen an einem vertrauenswürdigen Ort liegen müssen.

Für Dynamo läuft es auf dieselbe Frage hinaus, nur mit anderen Begriffen. Auch dort gibt es Pfade für Graphen und für Packages, und auch dort ist die Frage, ob diese Pfade in einem Bereich liegen, den das Team gemeinsam benutzt und der nicht von jedem beschreibbar ist. Dynamo Player greift auf einen Ordner zu, in dem die Graphen liegen; genau dieser Ordner ist der Ort, den ihr einmal ordentlich einrichtet.

Was in eine gemeinsame Liste gehört und wie kurz sie sein darf

Eine Tabelle mit sechs Spalten reicht für die meisten Büros vollständig aus: Name der Routine, was sie tut in einem Satz, wer sie verantwortet, welche fremden Bestandteile sie braucht, mit welcher Programmfassung sie zuletzt geprüft wurde und wann das war. Mehr Spalten führen dazu, dass die Liste nicht gepflegt wird, und eine ungepflegte Liste ist schlimmer als keine, weil sich jemand darauf verlässt.

Der eigentliche Wert dieser Liste zeigt sich zweimal. Beim Fassungswechsel sagt sie euch, was tatsächlich geprüft werden muss, statt dass ihr fünfzig Dateien durchgeht, von denen zwölf benutzt werden. Und beim Weggang eines Kollegen sagt sie euch, welche Routinen jetzt ohne Verantwortlichen dastehen, bevor das jemand schmerzhaft herausfindet.

Ergänzend gehört in jede Datei ein kurzer Kopf mit denselben Angaben. Das klingt doppelt, ist es aber nicht: Die Liste geht irgendwann verloren oder wird nicht mitgezogen, die Datei bleibt. Wer zwei Jahre später eine Routine öffnet und darin liest, wofür sie gedacht war und wer sie geschrieben hat, spart sich eine halbe Stunde Rätselraten.

Versionsverwaltung: sinnvoll, aber nicht um jeden Preis

Für Teams, in denen ohnehin jemand mit Git umgehen kann, ist ein Repository der beste Ort für AutoLISP-Dateien, Python-Stücke und Dynamo-Graphen. Textdateien lassen sich vergleichen, Änderungen sind nachvollziehbar, und eine versehentlich kaputte Fassung ist in einer Minute zurückgeholt. Der Weg von dort in die freigegebene Ablage ist dann ein einzelner Schritt, den man auch automatisieren kann.

Für alle anderen ist die ehrliche Antwort: Ein Ordner mit datierten Ständen und eine Textdatei, in der steht, was sich geändert hat, ist deutlich besser als nichts und wird tatsächlich benutzt. Eine Versionsverwaltung, die niemand bedienen kann, führt dazu, dass die Dateien wieder per Mail wandern und das Repository leer bleibt. Fangt mit dem an, was das Team wirklich pflegt, und rüstet später auf.

Ein Sonderfall sind Dynamo-Graphen: Sie sind zwar Textdateien, aber der Vergleich zweier Fassungen ist im Editor kaum lesbar. Hier hilft weniger die Werkzeugwahl als die Disziplin, im Graph selbst zu beschriften, was ein Bereich tut. Autodesk stellt für diesen Zweck eine Vorlage bereit, die eine feste Gliederung aus Eingaben, Variablen, Funktionen und Ausgaben vorgibt und dazu rät, Bereiche zu gruppieren und zu benennen.

Der Fassungswechsel: eine Liste, ein Vormittag, ein Ergebnis

Der Ablauf ist immer derselbe und lohnt sich, weil er planbar ist. Nehmt die Liste der tatsächlich benutzten Routinen, richtet einen Testarbeitsplatz mit der neuen Programmfassung ein und führt jede Routine einmal an einer echten Zeichnung oder einem echten Modell aus. Was läuft, wird abgehakt und mit der neuen Fassungsnummer versehen. Was nicht läuft, bekommt eine Zeile mit der Fehlermeldung.

Anschließend entscheidet ihr je Fall, und zwar bewusst: reparieren, ersetzen oder abschalten. Für Routinen, die nur noch eine Person benutzt, ist Abschalten oft die richtige Antwort, weil der Aufwand für die Pflege den Nutzen übersteigt. Wichtig ist, dass diese Entscheidung sichtbar getroffen und mitgeteilt wird, statt dass jemand im Projekt darauf stößt.

Rechnet dabei mit den typischen Ursachen. Bei Dynamo sind es fehlende oder geänderte Packages und umbenannte Nodes. Bei .NET-Erweiterungen ist es die Bindung an eine bestimmte Fassung der Programmschnittstelle. Bei AutoLISP sind es meist geänderte Befehlsabläufe oder Systemvariablen, seltener die Sprache selbst, was AutoLISP im Vergleich zu allen anderen Wegen bemerkenswert langlebig macht.

Und plant den Prüftermin vor das Ausrollen, nicht danach. Eine Woche vorher hat die Prüfung noch Wirkung, weil ihr entweder reparieren oder das Ausrollen für die betroffene Gruppe verschieben könnt. Eine Woche danach ist sie eine Bestandsaufnahme des Schadens.