Closed jakubjezek001 closed 4 months ago
i agree that relying on $PATH is not the best way to go. in general i think we shouldn't mess with PATH.
when adding these paths do function or class signatures... does this mean a user would have to always pass these in?
we could also think about fallback logic. something like this pseudocode:
oiiotool = "oiiotool.exe"
if oiiotool not in PATH:
oiiotool = LabLib.settings["oiiotool_path"] # or maybe use LABLIB_OIIO_ROOT
# now we can still inject a path for a function given that the function accepts this parameter
that way we would support binaries that may already be present in $PATH, let a user configure a custom path by either using a config file or environment variables (LABLIB_OIIO_ROOT
, LABLIB_FFMPEG_ROOT
) and ultimately let a user inject a path specifically for a class or function
should we maybe also add a check in start.ps1
if binaries are available and downloads them if not?
The LabLib currently relies solely on the PATH environment variable for the existence of oiiotool and ffprobe. We must also take into account scenarios where LabLib is integrated with AYON or other frameworks. In these cases, the paths to oiiotool and ffprobe may not be set through environment variables. Instead, they should be provided directly to classes or methods as input arguments.