[Feature Request]: Better ESP-IDF Version management (VSC-1259)

[JarrettR]

Is your feature request related to a problem? Please describe.
Using multiple versions (eg. V4.4, alongside V5.1) of the ESP-IDF on one system is a pain, and very error-prone.

The way to do it seems to involve actual folder management on the system, and I've never been able to get it working quite right, especially with different IDF versions expecting specific version of the Espressif tools.

Honestly, generally, I find it easier to just delete the IDF folders entirely and start the setup procedure from scratch with the IDF version I need to use for that project.

Describe the solution you'd like
Another option in the "ESP-IDF Setup" window that can swap in between different IDF versions.

Additionally, a section at the bottom status bar, right next to the ESP32 chipset (esp32, esp32s3, etc) that shows the ESP-IDF version, and the ability to swap between them.

Describe alternatives you've considered
A clear and concise description of "officially recommended" procedures to swap in between IDF versions.

[github-actions]

This issue has been marked as stale since there are no activities, and this will be closed in 5 days if there are no further activities

[chipweinberger]

yes i've asked for this feature as well!

specifically the bottom bar switcher

#832

[brianignacio5]

The question would be how to handle these multiple versions together ?

One way is to use the same IDF_PATH and change versions by changing git branches with git. This will also requires to install IDF Tools and update submodules of IDF which can take some time in the back. The advantage of this is that you only need a single IDF_PATH

Another is to have several IDF_PATH in our systems corresponding to different versions. Tools could exist in the same IDF_TOOLS_PATH and changing between one and another is as simple as updating the idf.espIdfPath to the new IDF_PATH location. There is already a way to update IDF_PATH for a single project by using existing setup in your systems with the setup wizard but saving it for the current workspace folder. The advantage of this is that a user can have multiple IDF versions for same system living together.

In my opinion the second choice is more favorable, and it comes down to why is it hard to currently change between multiple IDF versions in your systems, since at the end is just updating idf.* settings in settings.json (assuming current IDF versions are already properly configured).

The part of the IDF version switcher can be simple to implement after we understand 1 question:

1. How can the extension knows which IDF versions are in your system? How to determine this?

The options of choosing different IDF setups is already available in the setup wizard with Use existing setup. It will shows all options you have previously used by the extension and allow to choose between those without any additional install step. This is saved in the extension global state and can be cleared at any with Clear IDF setups button.

[chipweinberger]

1. yes, each setup should have different IDF_PATH & IDF_TOOLS_PATH imo
2. How can the extension knows which IDF versions are in your system? yes, saving old configs after setup seems best

I think a bottom switcher, that is saved per workspace / folder would work well.

[JarrettR]

1. I agree, different IDF_PATH/IDF_TOOLS_PATH makes the most sense.
2. I'd guess that there would be a set of configuration values for each IDF version that get added when we install a new one through the extension. With a default name of the version of IDF in the same way that the installation menu shows - That is, V4.4, release/V4.4, master, etc

That has the advantage of being more portable across machines, too, I think.

A setting of "idf.idfVersion" (or whatever) in the user settings.json would grab the right version on the host machine, or error out, potentially. This is better than having to specify the version in the readme. I'm noticing more ESP32 projects on Github being spread out among more and more different versions for a variety of reasons.

[github-actions]

This issue has been marked as stale since there are no activities, and this will be closed in 5 days if there are no further activities

[SolidStateLEDLighting]

I have had good success with multiple versions.

Here is a strategy that worked for me:

1. You install your version through ADVANCED option. Always allow the tools to install in the same directory for all versions.
2. Make a test application in a folder that you mark for that IDF version.
3. That test application holds all the correct paths for the tools for which that IDF version work with inside the .vscode directory (c_cpp_properties.json and the settings.json).

If you need another version -- repeat with ADVANCED option.

You may move from project to project and each will build from the IDF and tool which are specified in c_cpp_properties.json and settings.json configuration files.

By default all new projects are started from your last chosen IDF version -- but if you need to re-point that to another version -- go into USE EXISTING SETUP and select the version you want to activate. All new projects and sample will pull from chosen version.

[brianignacio5]

Could you test the PR #1173 with a proposed solution for this ? Or this vsix installer

@JarrettR @SolidStateLEDLighting @chipweinberger

[JarrettR]

This is fantastic, works well. I'm stoked.

[mtraven]

This is fantastic, works well. I'm stoked.

be carefull, I worked with method out a little while ago & I've noticed a few errors. I do a couple things differently than outlined here: I had a dedicated tools folder for each framework.(see attached image)

probably a lot of redundancy, but its much cleaner, if I ever have a problem with a tool chain, I can just deleted it & reinstall...that would be difficult with all the different tool chains piled in one folder.

I also dont do it system wide like that, I have it on a per project basis. Not to say that one is right or wrong, depends on your use. for example, right now I have a project that is 2 code bodies: one in 5.2 and one in 4.4.7, not in the same workspace, but I like to have them both open in different vscode windows. With the method described here, you cant do that, both projects will change into whatever framework you've selected. To do that, you need to change the IDF configuration save scope(ext settings). I outline that in detail here:

here are the bugs / undesired behavior I've noticed:
-when using an example file, say IDE 5.2. make the example file, the project will be in 4.4.7 (for me)--I believe that to be the first framework I added & thus some sort of default.
-correcting this ( configuring IDF @ the workfolder scope), reveals additional odd behavior: Say I selected 5.2 from my existing setups. the top half (framework) says its loading the version thats already in play (4.4.7), the bottom half(tools) says its loading the 5.2 tools! And that IS exactly what it does. Running the config a second time, activates 5.2 framework AND tools.

**NOTE TO DEVELOPERS: please bring back the save scope selection on the configuration menu, that would be handy, not sure why you changed it to just a read out. (i know how to change the settings, its just inconvenient )

[brianignacio5]

Hi @mtraven Thank you for your feedback.

I want to go through a few points from your comment.

1. The ESP-IDF: Configure ESP-IDF extension setup wizard command does use the idf.saveScope to decide where to save settings in settings.json. This will create an existing IDF Setup entry for the dropdown in the IDF Version switcher and Use existing Setup section of the setup wizard. This should allow to later use them in specific workspace folder project which is the goal of this version switcher and why is limited to workspace folder scope (so it doesn't mess with the global User settings scope)
   If you want them in different folders, just choose a different destination for IDF_PATH and IDF_TOOLS_PATH in the setup wizard and it should match with your directory structure.

2. Could you describe me where do you see this top half and bottom half, I'm not clear which part of the extension do you mean. Doesn't the IDF_PATH and IDF_TOOLS_PATH pair match the setup saved in the extension existing setups ?

3. About the example creation process and the resulting IDF version used. We can separate into 2 situations:
   a) You don't have any ESP-IDF project opened and vscode is using the global user settings. In that case when you create an example (using New Project Wizard or Show Examples) it will use the global user IDF version and tools.
   b) You have a ESP-IDF project already opened which has IDF settings for workspace folder. In that case when you create an example (using New Project Wizard or Show Examples) it will use the workspace folder IDF version and tools.

On my tests I observed that when I select a new version from the dropdown and later run the doctor command I would see. the right tools for the IDF_PATH and IDF_TOOLS_PATH. Isn't this the case for you ?

[chipweinberger]

congrats on this feature @brianignacio5 !!! 🥳🥳🥳