Allow user to override path assumption for system-provided modules

aboutcode-org / scancode-plugins

A set of plugins either delivered as builtin scancode-toolkit or extra plugins

2 stars 8 forks source link

Allow user to override path assumption for system-provided modules #9

Closed priv-kweihmann closed 3 years ago

priv-kweihmann commented 3 years ago

by optionally using environment variables

priv-kweihmann commented 3 years ago

@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. LD_LIBRARY_PATH is pretty invasive.

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

priv-kweihmann commented 3 years ago

BTW does that somehow need to be documented here? If yes, please point me to the right doc to edit

pombredanne commented 3 years ago

@priv-kweihmann you wrote:

BTW does that somehow need to be documented here? If yes, please point me to the right doc to edit

We can start with a simple doc statement in the README of each plugin.

And beyond this we may want to put this in:

the main scancode-toolkit documentation @AyanSinhaMahapatra which place would be best in https://github.com/nexB/scancode-toolkit/tree/develop/docs/source ?
https://github.com/nexB/typecode README (it does not have a proper doc yet otherwise)
https://github.com/nexB/extractcode README (it does not have a proper doc yet otherwise)

priv-kweihmann commented 3 years ago

New version pushed, including some brief documentation in the respective plugin dir - let me know if there is more to do from my side

AyanSinhaMahapatra commented 3 years ago

@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?

pombredanne commented 3 years ago

@priv-kweihmann Thank you ++ let me merge all this as well as this other PR https://github.com/nexB/extractcode/pull/18 by @tardyp which is closely related. I will refactor the code to get this cascaded behaviour as a generally available and documented way to get pre-built binaries across all the tools and libraries:

if there is an environment variable that points to a path use this
otherwise try to get a plugin-provided path (which could be a bundled binary or a path provider)
otherwise try to get a path from well-known locations (these may be OS-specific)
otherwise try to get a path from the PATH (e.g. which)
otherwise fail with a descriptive error message exposing remediation options