Skip to content

User settings

Settings govern your use of Tatin

Your Tatin user settings specify your ‘known registries’ – the Tatin registries you want to use – and some other settings you might use if you publish packages yourself.

When you launch Dyalog1, it reads your Tatin user-settings file

tatin-client.json

into ⎕SE.Tatin.MyUserSettings, a class instance. If you don’t have a Tatin user-settings file, Dyalog creates one in your home folder.

The default user-settings file lists two registries:

      ]ListRegistries
 Alias       URL                     ...
 ----------  ----------------------- ...
 tatin       https://tatin.dev/      ...
 tatin-test  https://test.tatin.dev/ ...

Edit your settings

Edit your settings with the user command

You can use any editor to change your user-settings.

On launching Dyalog, Tatin checks your user-settings file is valid JSON5 and signals any errors in it.

If you use the user command 

]TATIN.UserSettings -edit
to edit the file, Tatin will check the file when you save it.

Other settings define the defaults used when you create a new package.

group group name your packages will use
license license you usually use to publish a package
maintainer email address of the maintainer of your packages
source name of a folder in your package where all source files are stored

JSON5 allows comments.

Editing your user-settings file leaves your current user settings unchanged. To update them from the file:

]TATIN.UserSettings -refresh

To save your current user settings to file:

⎕SE.Tatin.MyUserSettings.Save 1

Cache settings

To reduce network operations, Tatin caches all packages by default, except

  • beta versions
  • packages from registries with an Any delete policy

Best delete policies for remote Tatin registries are None or BetasOnly.

Properties of ⎕SE.Tatin.MyUserSettings control caching for all known registries.

caching flag whether caching is enabled
path2cache string path to cache folder; defaults according to OS

The noCaching flags in tatin-client.json toggle caching for specific registries.

Caching is most commonly disabled for local registries hosting packages being developed.

]TATIN.Cache

Keeping settings elsewhere

For most purposes all you need is a single user-settings file in its default location.

In some circumstances you might prefer to keep your user-settings file elsewhere:

  • You need different settings for corporate and personal projects.
  • You need to edit the settings but do not have write access to your home folder.
  • Your computer is shared with others, at least one of whom needs write access to the settings.

First, change the current user-settings location: 

      p←,⊂'/path2/user_config_file/'
      ⎕SE._Tatin.Client.MyUserSettings←⎕SE._Tatin.Client.⎕NEW ⎕SE.Tatin.UserSettings p
      ⍴⎕←1 ⎕se.Tatin.ListRegistries 0
tatin      https://tatin.dev       ... 0 100 0
tatin-test https://test.tatin.dev  ... 0   0 0
2 7
      ⍴⎕←⎕se.Tatin.MyUserSettings.ListRegistries 0
 Alias  URL                  Port  Priority No caching Proxy API-key
 -----  ------------------   ----  -------- ---------- ----- -------
 tatin  https://tatin.dev/      0       100          0           ***
 test-tatin  https://tatin.dev/ 0       100          0           ***
2 7
Then make the new location the default: 
      ⎕SE.Tatin.MyUserSettings.MakeDefaultFile 1

id

A unique key that can be used to identify a Registry definition in the user settings file when neither the URL nor an alias can be used for this.

However, because mot of the time URL or alias are sufficient for this, setting id is optional.

The "id"

Because it must be possible to define more than one set for the same URL --- for different groups! --- in the user settings, the URL does not necessarily qualify as a unique key for a Registry. Neither does the alias, because it is optional, and you may reset it to "undefined".

So we need a unique key for this (though admittedly not many will be in need for this). That's why you may set "id".

This has only an impact locally in a scenario mentioned above, and that's why this is optional.

  1. Tatin is initialized either explicitly or as a side effect when the first Tatin user command is issued.  ↩