Update libraries from lib_deps (in VSCode)

First, it doesn’t appear to me that PIO updates libraries from the lib_deps list after the initial install – is this correct? Does PIO check the version of the library installed through using the lib_deps list?

If this isn’t the case, what is the “best practice” to keep a lib_deps library updated to the tip of a branch? (I’m guessing you could delete the libdeps_dir and let PIO reacquire the libraries – but that seems clunky).

Can anyone shed some light?

Yes, this is the correct and default behaviour. It does not change the version of the libraries without you specifically instructing it to. Bad enough when you create your own bugs… you don’t need an update to a library or platform you didn’t expect to cause them.

You can do updates either through the GUI (explicitly just update, as shown here on VSCode, or via the Libraries view of PIO Home)…

… or the command line (platformio lib update) …

https://docs.platformio.org/en/latest/userguide/lib/cmd_update.html

… or change the setting so it periodically checks for updates …

https://docs.platformio.org/en/latest/userguide/cmd_settings.html#auto-update-libraries

1 Like

ok - I understood that, but generally most libraries are released based on a tag, and hence, no changes will be made.

I know this is an edge case – so I won’t dwell too long here. The idea was for library development. If I have a library I am developing, I want to be able to pull in the changes to the project locally to do some testing of the library. The way to ensure this is to delete the library in the libdeps folder, correct? I was incorrectly thinking that the library manager would look for changes in the repository itself and pull in the changes.

If anyone doing library development has some tips on how they do development and can share them here, that would be great! I think I’m going with keeping a completely separate repo for the library, and point lib_deps to the local repo. Then delete the libdeps folder on each build.

I’ve been doing it a much more clunky way (but it still works) by either developing within a project folder, or hard/softlinking to the library folder. Either way, I wasn’t using lib_deps.

For library development, I’d either just clone the lib into the \libs folder, and use a separate tool like GitKraken to keep it up to date / push/pull changes, or use a extra_script to do a git pull on every build if that’s the way you wanted to go.

But yes, deleting the library in the libdeps folder is another way to force it to be updated, which could also be done through an pre extra_script.

Hi @Brett :wink:

I think the best solution here is to use lib_extra_dirs option. So, you can keep your library source code outside testing projects. For example, you do library development in /development/embedded/my-libraries/fooLibrary, then in platformio.ini:


[env]
lib_extra_dirs = /development/embedded/my-libraries/fooLibrary

[env:myboard1]
platform = plaform1
...

[env:myboardN]
platform = plaformN
...

Will it work? I would be thankful for any hints on how can we improve this workflow. This is very common questions from our community.

1 Like

For me with vscode lib-extra-dirs breaks the links to the file with the error. When you click on the error it says it can’t find the file and asks if you would like to create a new 1 with the path being the path to the file twice. like ‘/home/jmnc2/doc/ardunio/library/home/jmnc2/doc/ardunio/library/file.h’