Preferences¶
The Preferences dialog is found in the main menu of Sympathy as Preferences, on Windows as File -> Preferences.
Generally, the options shown and configured are global and tied to the settings. As a side note, settings are stored in a file called Sympathy.ini under the current Sympathy user’s folder.
General¶
Section dedicated to the main user interface and behavior of Sympathy.
Node Libraries¶
Shows the current global node libraries.
Global node libraries that have been added by selecting its folder on disk are shown and configured in this Section.
Global node libraries that have been added by installing Python packages into the Python environment are shown but can not be added or removed in this section. They are normally, managed outside of Sympathy by installing and uninstalling their corresponding python packages through pip, etc.
Python¶
Shows information about the Python environment.
Interpreter
Version
Architecture
Python paths
Packages
Python paths and packages can be modified from this section.
Python paths¶
Python paths can be modified in this section. This will add or remove global search paths for python modules. Modify only if you know what you are doing. In many cases, it is better to package python dependencies with libraries than to modify Python paths.
Packages¶
Lists installed Python packages and their corresponding versions.
Packages can be added or removed, with safeguards to avoid breaking the application. The version field is only used when installing.
Details: Add and Remove will run pip install and pip uninstall respectively. Before adding a package Sympathy checks that the request will not upgrade any package that Sympathy or its current plugins require. This ensures that package install from within Sympathy will not risk making the application unable to start or introduce other problems due to changed versions. Packages that Sympathy depends on can be changed outside of Sympathy by running pip install directly, be aware that it may break the application. Before uninstall the same check is made as for installation, and additionally, Sympathy checks that no package is uninstalled which another installed package depends on. Similarly as for installation, pip uninstall can be run outside of Sympathy to remove packages that can not be removed inside of Sympathy.
Environment¶
Shows the global environment variables, these are stored in settings and can be configured.
Additionally, this section shows the external environment variables (called Environment variables). These might come from settings in the operating system or the shell used to start Sympathy, etc. External environment variables can only be viewed but not configured.
Debug¶
Shows options for configuring the profiler and its output. Profiling requires the Graphviz executable (dot), and its location can be specified here. Or by making it available through PATH.
To obtain a copy of Graphviz, visit: http://www.graphviz.org.
Advanced¶
Shows advanced options that users should not normally need to configure. Notably an option to configure the number of worker processes and to disable or enable deprecation warnings.
Credentials¶
Stores sensitive information like logins and tokens separately from the node’s configuration. It can be used for authenticating to SQL databases, REST APIs, etc. without having to hard-code the information required and can help to make workflows safe to share. Unless you are sure that a workflow will always be private we recommend using credentials for authentication.
There are two kinds of credentials supported by Sympathy. Login and Secrets. Login credentials are used to authenticate with username and password. Secrets is intended for custom authentication scenarios, like HTTP requests using API tokens.
Before using credentials, first read the section about Security. If you do not want to use credentials change When requested to Deny.
In a headless environment, credentials can be passed via environment variables.
Login¶
Used for username and password authentication. The system will take care of inserting the username and password. Login credentials are recommended for authenticating when username and password is sufficient.
Optionally, resource name can be specified for use in place of the resource itself as key for storing and loading the login information. This can be used for sharing the same login for multiple resources by using different resources with the same resource name. It can also be used to allow different logins to the same resource.
Example (SQL Alchemy connection URL to PostgreSQL with login):
- Resource
postgresql+psycopg2://localhost:5432/mydb
- Username
my
- Password
secret
- Effective resource
postgresql+psycopg2://my:secret@localhost:5432/mydb
Example (HTTP URL with login):
- Resource
http://localhost
- Username
your
- Password
secret
- Effective resource
http://your:secret@localhost
Secrets¶
Secrets are variables in the resource, with keys written inside of angular brackets, that are used in place of typing their corresponding value in plain text. All secrets have a key: a string that will be used to identify them and an associated secret value. Supported key names start with a letter followed by more letters - or digits. Secret names are global identifiers, take care to choose unique key names to avoid conflicts. For example by adding some prefix.
Example (HTTP URL with token):
- Resource
http://localhost?api_token=<my-api-token>
- my-api-token
123123
- Effective resource
http://localhost?api_token=123123
Multiple secrets can be used as part of the same resource.
Security¶
Credentials are stored in a relatively secure way using the keyring package. On Windows it uses Windows Credential Locker on MacOS it uses Keychain. On Linux, Secret Service or KWallet will be used.
Warning
A word of caution, storing passwords in such a way that they can be accessed without requiring user interaction also means that they can be accessed by anyone who can log on as your user. Normally this should only be you!
Please keep this in mind if you plan to use this credential system for storing sensitive passwords or tokens.
Azure¶
Azure credentials are similar to login credentials. The main difference is in the way that you login and how they are stored. Multiple credentials can be created with the same name if the client is different. This makes it possible to use the same name (even empty name) for all azure credentials in a workflow.
Login takes place in a web browser dialog where you can login with your Microsoft account. The password is never accessed by or read by Sympathy, instead Sympathy receives an access token for your user.
On Windows, access tokens are stored in a single file encrypted by Windows APIs, unlocked by your current user. On Mac OS and Linux, they are stored like secrets or login credentials with one difference. Instead of multiple entries the information for all logins is stored in a single entry, this may change in the future.
