Lib finder priority strange behavior

Hi guys,

I’m working on a new organization of my lib called Luos : GitHub - Luos-io/luos: This Turborepo combines the whole documentation, website, services and blog about Luos.
In this new organization, I have examples on the lib (previously we had a specific repo for this, that was a mess), and also I have renamed the lib from Luos to Luos_engine (Luos engine name have not been released yet).

Examples are normal Platformio projects with platformio.ini and stuff. I would like to make them compile using the Luos_engine local sources.

If I have the Luos_engine source on the folder pointed by PLATFORMIO_LIB_EXTRA_DIRS everything works. But I want to make it straightforward for users so I added a lib_extra_dirs = ../../../../../ on examples platformio.ini allowing them to find the lib source, and this is half working…
For example for a button example I get :

Scanning dependencies...
Dependency Graph
|-- <Button> 1.0.0
|   |-- <Luos> 2.2.0
|   |   |-- <LuosHAL> 0.5.2
|-- <Luos_engine> 2.2.0

The nested dependency of Button is luos/Luos_engine, but it find the luos/Luos lib coming from the Platformio registry the other ones are coming from my local sources!

Is this normal?
Is there any simple way to make it compile using the local sources by default?

I think, yes. You have a strict dependency on the library from the registry. Could you try to remove dependencies field from the Button library manifest? PlatformIO will automatically detect library from your extra storages.

Yes, you’re right it’s working.

Why is it different between lib_extra_dirs and PLATFORMIO_LIB_EXTRA_DIRS ?

Also when I use this my local lib extraScript is launched twice before compilation…
Can I avoid it?

This is normal behavior, development platforms can interact with LDF as many times as they need. If you work with file system or other data, you can use the global marker to handle this:

extraScript

visited_key = "__LUOS_CORE_SCRIPT_CALLED"
global_env = DefaultEnvironment()
if visited_key in global_env:
    return
global_env[visited_key] = True

# your code

Ok I will do that, thank you.

@ivankravets I used the global marker tricks to avoid multiple script execution, but by doing that the first compilation fails (the second one work even after clean).

In verbose compilation, I can see that the added path of the script is missing but the script is perfectly executed the first time.
Is the multiple executions needed in some way?