multiple 'src/lib' directories

[mbrightcpacket]

The bashly add lib functionality is incredibly useful because it prevents code duplication. It would be really nice if we could specify multiple such directories, pulling in all the functions and code defined in them into the final script. In this manner, there could be separate Bashly scripts selecting different combinations of lib directories. For instance, there could be the following three directories:

• aws (AWS related functions)
• azure (Microsoft Azure related functions)
• common (common code that cross-cuts both clouds)

Two bashly scripts could be configured as follows:

• aws.sh could use aws and common
• azure.sh could use azure and common

Is there a way to achieve this in another way?

[DannyBen]

Well.

Right now, the source directory for library function is a single directory. There is no support for multiple "load paths".
Note however, that you can have as many subdirectories as you wish inside the src/lib directory (so you can group your functions as you please).

Also note that you can specify a different location for that directory in the settings.yml file, or via an environment variable.

But I suspect none of these answer your question directly - I was mainly ensuring we are on the same page.

As I understand, you wish to add another load path for libraries that is external to the directory of the specific bashly project, so that you can use the same lib directory for more than one bashly projects. Correct?

If so, then:

1. It is not supported at this point.
2. It is not a bad idea, I might implement it if there is interest.
3. You might be able to bypass this problem by using a symlink directory inside the lib directory, like this:

# In the aws project
src/lib/aws     # real directory
src/lib/common  # symlink to /wherever/functions/bashly-common

# In the azure project
src/lib/azure   # real directory
src/lib/common  # symlink to /wherever/functions/bashly-common

Not tested, but should work - although I agree, not ideal.

[mbrightcpacket]

I was thinking of the symlink approach too, I will go with that for now. Thanks for your quick reply!

[DannyBen]

Ok - I will think about it more.
There is high likelihood that the "main" lib dir will have to remain a single one, since it is used by the upgrade function (where you can upgrade built in libraries) - but, it might be relatively easy to add some also_include configuration that provides additional directories for inclusion of user directories.

Anyways - let me know how the symlink experiment goes, and if there is a need for a better solution.