Allow user to override path assumption for system-provided modules #9
Conversation
There was a problem hiding this comment.
Thank you ++ this makes sense.
Do you think it might be best to have a set of dedicated environment variables such as EXTRACTCODE_7Z_PATH, EXTRACTCODE_LIBARCHIVE_PATH and TYPECODE_LIBMAGIC_PATH and TYPECODE_LIBMAGIC_DB_PATH instead?
May be it is more explicit than overloading LD_LIBRARY_PATH?
|
@pombredanne I'm actually a little torn about this - on the one hand the usage of commonly known variable is what I would like to see, on the other I'm not sure about any possible sideeffects, as esp. So I guess it's better to follow your proposal, even if it mean having a larger env set to mind when building - will push a v2 somewhat soon |
|
BTW does that somehow need to be documented here? If yes, please point me to the right doc to edit |
|
@priv-kweihmann you wrote:
We can start with a simple doc statement in the README of each plugin. And beyond this we may want to put this in:
|
priv-kweihmann
force-pushed
the
system-provided-better-override
branch
from
9d45c19 to
402bf7b
Compare
|
New version pushed, including some brief documentation in the respective plugin dir - let me know if there is more to do from my side |
|
@pombredanne I think there should be a list at https://github.com/nexB/scancode-toolkit/tree/develop/docs/source/plugins with all available ones, that would make sense. If that was what you're asking, should that get a separate issue? |
let the user override assumed paths via environment. EXTRACTCODE_7Z_PATH is used to determine the path of the 7z executable. If not specified it falls back to previously used probe of distro data. With this patch it possible to run scancode is buildsystems like YOCTO, which heaviily rely on overriding paths via environment to pick the correct implementation from the build workspace Signed-off-by: Konrad Weihmann <[email protected]>
let the user override assumed paths via environment. TYPECODE_LIBMAGIC_PATH environment variable can be used to explicitly set the path to libmagic.so. If not specified it falls back to previously used calculation from distro data. Location of the magic database can be specified via TYPECODE_LIBMAGIC_DB_PATH environment variable. If not found it falls back to the previous bevahior. With this patch it possible to run scancode is buildsystems like YOCTO, which heaviily rely on overriding paths via environment to pick the correct implementation from the build workspace Signed-off-by: Konrad Weihmann <[email protected]>
let the user override assumed paths via environment. Path to libarchive can be specified via EXTRACTCODE_LIBARCHIVE_PATH environment variable. If not found it falls back to previously calculation from distro data. With this patch it possible to run scancode is buildsystems like YOCTO, which heaviily rely on overriding paths via environment to pick the correct implementation from the build workspace Signed-off-by: Konrad Weihmann <[email protected]>
priv-kweihmann
force-pushed
the
system-provided-better-override
branch
from
402bf7b to
627608d
Compare
|
@priv-kweihmann Thank you ++ let me merge all this as well as this other PR aboutcode-org/extractcode#18 by @tardyp which is closely related.
|
There was a problem hiding this comment.
Thank you ++
I am also porting your changes upstream in https://github.com/nexB/extractcode and https://github.com/nexB/typecode directly, so that it can work even if so plugin is installed.
We now load the libmagic native library and its database from paths found in: 1. environment variables, 2. OR a location provider plugin, 3. OR the system PATH, 4. OR we fail with an informative error message. Based on original code contributed by @priv-kweihmann to scancode-plugins in aboutcode-org/scancode-plugins#9 and moved here and adapted for use in the core code rather than in a plugin. Contributed-by: Konrad Weihmann <[email protected]> Signed-off-by: Philippe Ombredanne <[email protected]>
by optionally using environment variables