Skip to content

arduino-cli standalone install looks for .cli-config.yml in wrong location #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
UffeJakobsen opened this issue Sep 4, 2018 · 19 comments
Labels
type: enhancement Proposed improvement

Comments

@UffeJakobsen
Copy link

arduino-cli standalone install looks for .cli-config.yml in wrong location

arduino-cli looks for .cli-config.yml in wrong location when installing a standalone arduino-cli binary into /usr/bin/
In the above case it looks for /usr/bin/.cli-config.yml - and does not even try to look inside my home dir

See the debug output:

# arduino-cli board listall --debug
INFO[0000] Initiating configuration                     
INFO[0000] Unserializing configurations from /usr/bin/.cli-config.yml 
WARN[0000] Error reading config, using default configuration  error="open /usr/bin/.cli-config.yml: no such file or directory"
WARN[0000] Did not manage to get config file, using default configuration  error="open /usr/bin/.cli-config.yml: no such file or directory"
INFO[0000] Checking if CLI is Bundled into the IDE      
INFO[0000] Candidate IDE Directory: /usr/bin            
INFO[0000] CLI is not bundled into the IDE              
INFO[0000] Configuration set                            
INFO[0000] Starting root command preparation (`arduino`) 
INFO[0000] Formatter set                                
INFO[0000] Loading the default Package index            
Board Name	FQBN
@cmaglie
Copy link
Member

cmaglie commented Sep 14, 2018

Right, so the paths to look for the config file should be (in order of priority):

.
$HOME
/etc
/usr/bin (or the folder where the executable is)

At this point I'm wondering also that .cli-config.yml is a very bad name it should really be .arduino-cli.conf.yml (with the . prefix optional) so we have:

./arduino-cli.conf.yml (or even ./.arduino-cli.conf.yml)
$HOME/.arduino-cli.conf.yml
/etc/arduino-cli.conf.yml
/usr/bin/arduino-cli.conf.yml

of course this is for unix/linux, maybe Windows have different standards for command line?

/cc @mastrolinux @facchinm

@cmaglie cmaglie added bug type: enhancement Proposed improvement labels Sep 14, 2018
@ubidefeo
Copy link

ubidefeo commented Oct 8, 2018

I believe the first place for arduino-cli to look for a config file should be the sketch directory.
I like to have custom config on a per-sketch basis.
Now I'm forced to pass it to the command line and it's a downer.

ino compile -b arduino:samd:mkrzero --config-file ./cli-config.yml (mine is aliased as ino, c'est plus facile)

my priority order would be
.
$HOME/
/usr/local/etc
and whatever comes after that :)

@bxparks
Copy link

bxparks commented Oct 14, 2018

I think cli-config.yml should not be retrieved from the current directory at all, because it can cause confusing behavior.

The arduino-cli compile command allows the target *.ino file to be specified directly, instead of implicitly assumed to be in the current directory:

$ arduino-cli compile -b {board} path/to/file.ino

If reading from the ./cli-config.yml is allowed, it seems more correct for the config file in the target directory path/to/ directory to be used, in other words path/to/.cli-config.yml, instead of using the ./.cli-config.yml file in the current directory from where the arduino-cli command was executed.

Going up a level, I think the issue is whether the cli-config.yml file should be considered to be a property of the arduino-cli command, or a property of the *.ino sketch. I think the first option makes more sense, in other words, it is a configuration file of the arduino-cli program. In that case, it seems too confusing for the command to change its behavior depending on the location of where it was executed from.

Additionally, if multiple .cli-config.yml locations are allowed, then I think the precedence rules need to be made clear. In other words, are the individual properties in the config file merged and the last one takes precedence? Or does the last cli-config.yml take precedence over any other config file, clobbering any default values?

@ubidefeo
Copy link

Excellent points, @bxparks

having used PlatformIO a lot over the past years I am comfortable with having project-based configurations with different directives on a pre-project base, hence my suggestion to have multiple options for the location of such file.

I believe this .cli-config.yml should be relative to the project not the command itself (it is, in fact, an option on the command and not a requirement)

@cmaglie
Copy link
Member

cmaglie commented Oct 25, 2018

@ubidefeo which options you would like to set specifically for the sketch?

@ubidefeo
Copy link

@cmaglie more than sketch i think project/folder specific.
For instance in my dream scenario I can add all the configuration options in the cli-config.yml file (board, cpu, library path(s), core-speed, target, programmer the more the merrier) and maybe have multiple config files such as samd21G-config.yml or uno-config.yml.

at this point I could just run
arduino-cli --config-file ./uno-config.yml
arduino-cli --config-file ./samd21G-config.yml

in the case of Platformio I can do this by choosing a target (or assigning a default one).
I know they're two different approaches, but just to show you how I handle my configurations on a per-board/target basis here's a sample config file

[platformio]
env_default = mkrzero

[env:uno]
platform = atmelavr
board = uno
framework = arduino
upload_protocol = arduino
#upload_speed = 57600
#upload_port = /dev/cu.usbmodem14321
#upload_flags = -P/dev/cu.usbmodem14321

[env:micro]
platform = atmelavr
board = micro
framework = arduino
upload_protocol = arduino
upload_speed = 19200
upload_port = /dev/cu.usbmodem1411
upload_flags = -cavr109

[env:mkrzero]
platform = atmelsam
board = mkrzero
framework = arduino
#upload_protocol = arduino
#upload_speed = 19200
#upload_port = /dev/cu.usbmodem1411
#upload_flags = -cavr109

@ubidefeo
Copy link

something I forgot to mention:
I would love a config file to be able to contain every possible option you may want to use in the command line

@bxparks
Copy link

bxparks commented Oct 25, 2018

If .cli-config.yml is to be considered part of the sketch, then I would probably prefer the Arduino IDE to read it and follow its instructions as well. Otherwise, it's too confusing to keep track of 2 different ways of compiling the same sketch.

A side comment, why YAML? The YAML spec is 80 pages long, a full superset of JSON. Does the Arduino-CLI really need that much configuration? I think I would have preferred INI file, something that even novice programmers can understand, and already used by PlatformIO.

@ubidefeo
Copy link

I agree with @bxparks on a config file being also read by a future version of the desktop IDE.
I don't ask my YAML, and .ini is also a better option for me, but if YAML works I don't mind as I keep reading it as JSON without worrying about the specs :)

@wjwieland
Copy link

This is good conversation and I appreciate the views thus far. I am going to toss in my own.
My views assume the following:

  • arduino-cli will be incorporated in to the arduino-ide at some point

  • Config for one should not conflict with the config for the other. It may overlap with differences, but config contents and format should not throw warnings or exceptions regardless of whether one is using the CLI or the IDE.

  • There should be two levels of config: Application and project. Application level config should reside in one place for both the IDE and the CLI. It would seem to me like the ~/$HOME/.arduino_x is as good a place as any, but as long as the application level config is in one place for both it is fine.

The project level config seems like a good idea to me..., but.. both the IDE and the CLI should support that the same way, at the same time. If that can not be done without a lot of hair-pulling, then it should not be done at all.

As far as what the config format is, JSON, YAML, .ini: It does not matter to me.

  • I really like the idea of "All" CLI or other options being made available in the config file. (Unless there are those that simply do not make sense for some reason. Additionally, if this were the case, the config file distributed with either the CLI or IDE should be well documented.

Just my $0.02 worth...
Thanks to all for the work on this. When it is really ready and working (has yet to do so for me on my RPi ), it will be very, very useful to me!

@ubidefeo
Copy link

thanks for sharing and I'm glad you agree with some of my points :)

@wjwieland
Copy link

Two further comments:
Based on the fact that https://downloads.arduino.cc/arduino-cli/arduino-cli-0.3.2-alpha.preview-linuxarm.tar.bz2 seems to have fixed the functioning part of arduino-cli on both my RPi3 and RPiB2+, I am really pleased! This is a major improvement over ssh -X to my remote Pi and waiting forever for display-back!

Now that this is working nicely and I have had the time to play with it a bit more, my previous thoughts on config have been re-enforced a bit. Again, my assumption is that the CLI will be integrated and hopefully distributed with the IDE and/or vise-versa.

Having a project level config for controlling both the compile and upload could be handy as I see it. (much appreciate the 'arduino-cli config init' by the way! While it does not put much int the .cli-config.yml, it is good to be able to direct it to where one wants it to be, which sort of contributes to my appreciation of a project level config.

Again, that said, the more global config would certainly continue to have value as long as that global config applies to both the IDE and CLI. (no exceptions thrown by either regardless of exclusive applicability.

I am curious about one thing: Being that CLI is written in golang and the IDE is Java, will this make it hard to combine these two into a single application when the time comes?

@SConaway
Copy link
Contributor

What's going on here? At least can we add pwd to the list?

@sjackman
Copy link

I'm in favour of $HOME/.cli-config.yml and perhaps a per-project configuration file as well.

@SConaway
Copy link
Contributor

That sounds like a good idea. Where'd the per-project be located?

What's the ETA here? I can help test.

@opatut
Copy link

opatut commented Jan 29, 2019

It's not uncommon for these kinds of tools (e.g. language specific package managers like npm does with package.json) to take pwd and search upwards for the first directory that contains a file with the correct name, and consider that directory the "project directory". I love that mechanism because when I run a CLI tool in some kind of project scope, I'll definitely cd into that project directory first. Sometimes I also move around inside the directory.

Then, of course, "global" configs from known places ($HOME, ~/.config, /etc/<toolname>, /usr/local/..., ...) are searched in addition to the project-specific config.

I'd like that.

@ScottiSws
Copy link

I would like to see the file named $HOME/.arduino-cli-config.yml
cli-config is a tad generic.

@opatut
Copy link

opatut commented Feb 3, 2019

There is the standard $XDG_CONFIG_HOME for a reason, which points to $HOME/.config by default on most systems. The standard way of using that directory is to make a subfolder with the name of the application, i.e. it should be ~/.config/arduino-cli/config.yml, or more precisely, $XDG_CONFIG_HOME/arduino-cli/config.yml.

Looks like there is the configdir golang library for that.

@cmaglie
Copy link
Member

cmaglie commented Sep 12, 2019

We have made some improvements to config path search in #140. I'm closing this one since it has gone a bit off-topic and is difficult to follow the various suggestions.

If you have still problems please open a new issue and provide the current behaviour and the desired behaviour.

About 'environments' we will keep track of the progress here #108

@cmaglie cmaglie closed this as completed Sep 12, 2019
per1234 added a commit that referenced this issue Aug 9, 2021
Allow setting official check mode configuration via environment variable
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

9 participants