PlatformIO Community

Version control and library development

I’m working on my main code and I’ve need to modify someone else’s libraries.
So I forked a copy and I include that in my platformio.ini.

    lib_deps =
  # Using a library name

So I make the changes but under the source control tab I only see pending changes to my main program. Nothing about the library in .piolibdeps which I modified.

As you can tell I’m kinda newbie at this.
Am I going about this the wrong way?
Do I need to check it out via command line to a different folder and then specify that include folder? And then am I going to be forced to used the command line to make my commits?

I really like the visual notifications of changes vs stock…



Does VSCode show you the modifications to the library when you have opened one of its source files? What does git branch -a show in the library folders?

Btw because of the .gitignore containing .piolibdeps, git will not push the contents of that library into the repository of your main firmware.

No… VSCode doesn’t show the mods. Only my main code shows the mods.
git branch shows no branch

I’m guessing that it just downloads the code vs doing a checkout? I see the gitignore.
So do I have to manually checkout the library in a separate folder?
I can’t be the first one to do library development as well as main program development at the same time! :slight_smile:

You’re executing this inside the folder of your modded library, right? Which is where? What’s the full output?

It’s in the .piolibdeps/mylibrary folder
The output is
* (no branch)

If I go up one to the .piolibdeps folder and do it I get

* master
  remotes/origin/HEAD -> origin/master

Can you delete your .pioenvs again and rebuild the project. Do you see some output about a git clone?

I deleted the .pioenvs folder. Recompile. Nothing at all about a git clone.
Nothing at all about git.
I do see a .git file in the .piolibdeps/mylibrary folder. And I can see differences when I do a tortise git diff on the two library files I changed. So I guess I can manually commit the changes. But it would be nice to see them in the editor. I wonder if I comment out the piolibdeps in the git ignore file… hmm…

That will make it push .piolibdeps in your main firmware’s repo, which you probably don’t want. I’ll try out what the correct way is myself.


Did you get a chance to figure out the correct way to do this?



What do you see with pio run --verbose?

In terms of what?

In the beginning I see
LibraryManager: Installing mylibrary
mylibrary @ commitxxx is already installed

I think the problem you are facing here is because of nesting… you have your main code, which is source controlled in one repo, and you have your library (cloned into to .piolibdeps), source controlled in another repo. VSCode doesn’t seem to be able to hand the nesting… if you add the library folder to the workspace, try to open the git repo manually (View -> Command Palette -> Git open repository),etc it doesn’t seem to do anything. You’ll probably have to use the command line to manage the nested repo, or use a external GUI tool like Github desktop or TortoiseGit.

Ok… I guess I’m stuck using the external gui stuff. It would have been nice to have PIO or VSCode handle it. But if It’s not possible.
I can’t be the only one who’s developing a library and a main program at the same time.

Is there a better way to do it?

Could you provide a simple project to reproduce this issue with all details? Thanks!

Sure. I can try to set something up.
But… Maybe I’m just doing something wrong.

Say I have my main code in Repo A and I have my own library in Repo B.
How do I use my library in Repo B in my main code project in Repo A and still make and see changes to my library (repo B) while working in the main project?

I’m sure I’m not the only one that develops library code while working on main code…

What’s the best way to do this? If I import the library in plaformio.ini into .piolibdeps then it doesn’t track repo B.

Since what it sounds like you really want is for the library to be tracked the VSCode source control view… how about having that library in another folder, and adding that to the VSCode workspace? In other words, completely ignore the version in .piolibdeps… let platformio manage that copy.

i.e say for my tracerWifi project code, say I needed to make changes to the elaspedMillis library (which I’m a maintainer of) … so I have it set as a git style lib_deps dependency for my tracerWifi project, and git clone the elapsedMillis library somewhere else onto my computer (e.g. /home/pfeerick/repos/libraries/elapsedMillis) and then added that folder to the VSCode workspace… (File -> Add Folder to Workspace). You get source control views for your main code and for your library…

The only tricky bit I see happening is that in your main code, you might need an extra_script to ensure it always does a git pull if needed to ensure it has the latest commit of the library…

Actually, on second thoughts, I think your original idea was spot on… clone it out to a separate folder (e.g. /home/pfeerick/repos/libraries/elapsedMillis), add the library folder to the workspace, and then tell platformio about that libraries folder in your platformio.ini like lib_extra_dirs = /home/pfeerick/repos/libraries/ … that seems like it should work… you get both the locally editable library, which is used by your main code, and since you’ve added it separately to the workspace, it shows up in source control.

You should delete the copy of the library in .piolibdeps as you don’t want your main code using that version at all, and you don’t want it mentioned in the lib_deps of your main codes platformio.ini, else platformio will try to download it again, instead of using the copy in the lib_extra_dirs path.

1 Like

PS: I’m only just starting to look at it myself, but git submodules might be the way to do it ‘properly’… I just don’t know yet how the VSCode source control viewer handles it… or if I’ll just use GitKraken to manage them…

Addendum: It looks like the answer is ‘just fine’… Using a non-platformio-managed library, VSCode’s source control system correctly identified the submodule as a submodule, and added a handler for it… So with a bit of tweaking, that looks to be the better way to track nested repositories with VSCode also… as you’re basically acknowledging in the repo itself that they’re linked.