Platformio-core: Patterns: Global "[env]" section in INI file

[me21]

Please support src_filter directive in [platformio] section. Right now it is supported in [env] sections only, requiring it to be repeated for every build environment.

[ivankravets]

I've just edited this issue and moved to the next 3.6.0 release. [platformio] section is intended for internals PIO Core configuration. I think it's a bad idea to mix [env:*] and [platformio].

I propose to create global [env] section where we can define global options per ALL environments declared in configration platformio.ini. Default haviour is to EXTEND + REPLACE. If you need concatenation for the option values, please use dynamic variables described in http://docs.platformio.org/en/latest/projectconf/dynamic_variables.html

Original platformio.ini

[env]
platform = atmelavr
framework = arduino
upload_speed = 9600
lib_deps = 
  ArduinoJson
  RTC
src_filter = +<src/target/avr>

[env:uno]
board = uno

; override
upload_speed = 115200

; concat
lib_deps = OneWire ${env.lib_deps}
; cancel global option (just set to empty)
src_filter =

Computed platformio.ini

This is a result how PIO Core will see [env:uno] environemnt after parsing/computation.

[env:uno]
platform = atmelavr
framework = arduino
upload_speed = 115200
lib_deps = 
  OneWire
  ArduinoJson
  RTC
board = uno

---

@xoseperez, @lobradov, @zafrirron, @Misiu, @proddy would be thankful for your feedback!

[ivankravets]

Related issue https://github.com/platformio/platformio-core/issues/1590

[xoseperez]

This feature will be great for project maintainability.

[proddy]

agree. this will greatly simplify the build configuation for multiple devices and make the platformio.ini more versatile and portable

[xoseperez]

One concern: isn't env already used for environment variables? I mean, I can do this atm:

...
build_flags = -g -w -DMQTT_MAX_PACKET_SIZE=400 ${env.ESPURNA_FLAGS}
...

And then:

ESPURNA_FLAGS="-DNO_GLOBAL_EEPROM" pio run

[ivankravets]

@xoseperez you are right :( I even don't know what to do now. A lot of projects use ${env.*} as a pattern for access to OS environment.

Should we rename ${env.} to ${sysenv.*}? And show a warning message for old projects if they try to access ${env.} and there is no [env] in config?

[xoseperez]

env will always mean environmentand PlatformIO already uses it for the build environment (i.e. [env:..] sections) and for script environment (${env....}).

I'm sorry I'm back to my initial proposal, but why not using an explicit inheritance. See PR #790. If adding an extra include key is not an option, another way would be to use the section name like this:

[env:basic]
framework = arduino
platform = [email protected]

[basic:d1]
board = d1_mini

[basic:nodemcu]
board = nodemcuv2

[ivankravets]

All logic is built on top of [env:*] and it's easy for reading. We plan to add UI for platformio.ini into PIO Home soon. It will be difficult to reflect this "chained structure" into UI.

As practice shows, people don't like to edit this file manually :(

[xoseperez]

I think the whole point of this issue is to ease working with platformio.ini files, raw. There are tons of other formats that would probably be more suitable for a UI (XML, JSON, YAML,...) but if you stick to a .ini file focus should be, precisely, on making it easy to use with a simple editor.

BTW, I'm one of those that still edit the file manually... but I'm thinking on creating my own platformio.ini builder...

[ivankravets]

Yes, "INI" is so bad format for UI, there is no good library which will allow preserving comments, formatting in INI file. I see only https://pypi.org/project/configobj/

(XML, JSON, YAML,...

• JSON is bad as user configuration format. It's very easy to make type/mistake. We see this problem with library.json manifest.
• XML is hard if you decide to edit it manually
• YAML requires extra libraries.

I think INI is a compromise between manual & UI modes.

but I'm thinking on creating my own platformio.ini builder...

We have a separate issue for that, https://github.com/platformio/platformio-core/issues/1590

Will #1643 and #1590 cover all your requests?

[xoseperez]

Yes, I still think #1643 is a good step forward. Most of the time I'm doing ${common...} so maybe common is a good name for this base section.

[ivankravets]

Thanks! I'll check it. Need to take a look at the old configuration files with [common]. Will we break them...

What I propose in this issue:

1. Replace ${env.*} with ${sysenv.*}
2. Implement global/common [env].

[ivankravets]

https://github.com/platformio/platformio-core/issues/1705

PlatformIO Core 3.5 should support both versions: ${env.var} and ${sysenv.var}. ${env.var} should produce a warning and will be removed in the next PIO Core 3.6.

[ivankravets]

See updated docs http://docs.platformio.org/en/latest/projectconf/section_env.html

Please re-test with the latest development version of PlatformIO Core:

pio upgrade --dev

Test example => https://github.com/platformio/platformio-core/blob/develop/tests/test_projectconf.py