Environment variable for telemetry
I think it would be nice to optionally have an environment variable that holds my selection for opting in/out of telemetry, since developers are likely to choose the same option for every project and it is a little bit annoying to answer the question every time you create a new project.
My UI suggestion:
$ clarinet new demo
Send usage data to Hiro.
Help Hiro improve its products and services by automatically sending diagnostics and usage data.
Only high level usage information, and no information identifying you or your project are collected.
Enable [Y/n]?y
Telemetry enabled. Thanks for helping to improve clarinet!
To skip this prompt next time and always enable:
export CLARINET_TELEMETRY=1
Creating directory demo
Created file demo/contracts
Created file demo/settings
...
Hi @obycode and @lgalabru !
The idea to use environment variables to control some aspects of the clarinet is valid. Great idea... but the environment variable is not automatically persisted in the shell environment, it will work only once, unless the shell configuration is changed.
So - throwing an idea to discussion - what you think in adding a more robust configuration feature to clarinet? I mean a config file like the .gitconfig (or any other format) where clarinet can leverage of global and local (per project) configurations.
Cheers.
Hi @csgui. Thanks for the input. It does seem likely that we will have more customization options as time goes on, so you're right, it could be nice to create a config file.
Right now, I believe we just have the variable CLARINET_DISABLE_HINTS and this proposed new one.
Thanks @obycode, yeah good idea. Good point @csgui, I think a global config file would be a good move. It is actually going to be essential for the "Clarinet and beyond" project.
Hey @lgalabru and @obycode !
How the work of a feature like that - a config file - would be planned? I'd love to help on that. :-)
Hey @csgui!
You could look at how we're dealing with the Clarinet.toml manifest files: we essentially have a ProjectManifestFile where most of the fields are optional, then we have a ProjectManifest struct where all the fields optional in the 1st struct are required. ProjectManifest can be constructed from a ProjectManifestFile, and the values absent from the file are completed with default values.
By default, clarinet could be trying to load this file from ~/.clarinet/Settings.toml. I'd like to setup a directory (vs just a file) because that directory could be reused for other things, like caching for instance.
What do you think?
What do you think?
It's a fair point to start that feature. I'll check and keep you posted!