I am setting up OpenVino on my system and I get this form the documentation:
(Optional): OpenVINO toolkit environment variables are removed when you close the Command Prompt window. As an option, you can permanently set the environment variables manually.
But there is no information is available on what are the required environment variables and what value they should be set.
I need to know the list of environmental variable needed by OpenVino and the value that they should be set to. I know how to set them in Windows (using GUI or Setx).
The environment variables need to be set are given in the setupvars.bat file present at "path_to_computer_vision_sdk_directory\bin".
But I will give a general idea on the paths that need to be set -
Set the following System variables in your Environment Variables
Variable name: INTEL_CVSDK_DIR
Variable value: path_to_computer_vision_sdk_directory i.e.
C:\Intel\computer_vision_sdk_version_number, in case you have the cvsdk setup at the default path for installation
Variable name: OpenCV_DIR
Variable value: %INTEL_CVSDK_DIR%\opencv\cmake
Variable name: OPENVX_FOLDER
Variable value: %INTEL_CVSDK_DIR%\openvx
Variable name: InferenceEngine_DIR
Variable value: %INTEL_CVSDK_DIR%\deployment_tools\inference_engine\share
Variable name: HDDL_INSTALL_DIR
Variable value: %INTEL_CVSDK_DIR%\deployment_tools\inference_engine\external\hddl
Now edit the "Path" variable under System Variables to include the following values -
%INTEL_CVSDK_DIR%\opencv\x64\vc14\bin
%INTEL_CVSDK_DIR%\openvx\bin
%INTEL_CVSDK_DIR%\deployment_tools\inference_engine\bin\intel64\Release
%INTEL_CVSDK_DIR%\deployment_tools\inference_engine\bin\intel64\Debug
%HDDL_INSTALL_DIR%\bin
You also nee to set the "PYTHONPATH" to %INTEL_CVSDK_DIR%\python\python_version%
Related
I am using the Config crate in Rust, and would like to use environment variables to set keys inside a section of the config. The end goal is to override application settings from a docker compose file, or docker command line, using the environment.
If my config was the following, could I use a specifically crafted environment variable to set database.echo ?
(code blurb below is taken from this example)
debug = true
[database]
echo = true
The example code to configure this using the environment variables illustrates only to set keys at the top level. Wondering how to extend this. The .set() takes a hierarchical key, so I'm hopeful that there's a way to encode the path in the env variable name.
Answering my own question.
I just noticed that the Environment code accepts a custom separator which will get replaced with . (dot).
So one can set the separator to something like _XX_ and that would get mapped to a ".". Setting DATABASE_XX_ECHO=true, for instance would then change the database.echo key.
I use Terraform to provide some Google infrastructure. I would like to store some configuration variables in an external (non-terraform) config file. The idea is to use those variables in the Terraform and bash also, so I wouldn't like to use typical .tfvars file. How to achieve this?
I have got three files and let's assume for simplicity, that they are being stored in the same directory.
General configuration files with the variables to ingest:
# config.txt
GOOGLE_PROJECT_ID='my-test-name'
GOOGLE_REGION='my-region'
Terraform file with the datasources:
# datasources.tf
data "local_file" "local_config_file" {
filename = "./config.txt"
}
Terraform file with the variables:
# variables.tf
variable "project_id" {}
variable "region" {
default = 'europe-west3'
}
If all of your variables you'd like to use in Terraform are string-type variables, you can define them as environment variables to use them in Terraform and your Bash scripts:
Terraform will read environment variables in the form of TF_VAR_name to find the value for a variable. For example, the TF_VAR_region variable can be set in the shell to set the region variable in Terraform.
# config.sh
export TF_VAR_region="my-region"
export TF_VAR_project_id="my-test-name"
Note that this approach won't work for list or map type variables:
Note: Environment variables can only populate string-type variables. List and map type variables must be populated via one of the other mechanisms.
See the docs here for more information.
I have an API key I'm using in my Node.js application. Currently, I keep it stored in a text file and put it in a global variable when my application starts up.
So basically it's just:
var key = getKey();
useKeyGetData(key);
I don't like having this global variable, and it's a pain to pass between files. Is there a better way to get my key where/when I need it? Is there some standard for doing so?
The conventional alternative to what you're doing, especially when pertaining to API keys, is to use environment variables. This is an operating system-level configuration facility. Each process has its own set of environment variables, usually inherited from its parent process. By convention, environment variables have uppercase names.
In node.js, you can access environment variables through process.env. For example, if you run an application like this:
$ MY_VARIABLE=test node app.js
You can access the value of the MY_VARIABLE environment variable via:
process.env.MY_VARIABLE
It can be tedious, however, to have to keep passing the environment variable(s) on each invocation of your program. That's why there are packages such as dotenv which allow you to store your environment variables in a text file.
More specifically, you will have a file called .env and in it you might have:
MY_VARIABLE=test
OTHER_VARIABLE=foo
At the beginning of your app.js, you then do:
require('dotenv').config();
This reads the environment variable values from the .env file. You can then access them as you would access any other environment variables:
console.log("MY_VARIABLE: " + process.env.MY_VARIABLE);
console.log("OTHER_VARIABLE: " + process.env.OTHER_VARIABLE);
Now you don't have to explicitly pass the environment variables to your application upon invocation, i.e. you can just run it as usual:
$ node app.js
If you do pass one explicitly, it will override whatever value you gave in your .env file:
$ MY_VARIABLE=bar node app.js
Now the MY_VARIABLE environment variable will have a value of "bar" instead of "testing". Since OTHER_VARIABLE isn't passed explicitly, it retains its value of "foo" specified in the .env file.
Any environment variable prefixed with "FACTER_" is automatically added to the facter collection. I've successfully added a "FACTER_" environment variable it is indeed showing up in the facter -p list, so it should be able to be used by puppet...
The problem, though, is in my .pp file the variable name that should be set to the FACTER_ value is empty (or non existant)
Is there something else I need to do to get FACTER_ variables into puppet variables?
Cheers
You are most likely setting up the system so that the FACTER_ variables are available in interactive shells. This is not sensible if you want your background agent to respect them.
I can see two direct approaches:
Modify your initscript or its configuration to set the appropriate environment variables.
Forego the approach entirely and use /etc/facter/facts.d instead.
I would advise towards the latter.
We have a build script which build three types of projects - C++, Java and finally the respective InstallShield installers.
Right now the installer build script relies on the fact that the C++ projects are always built in the Release configuration.
But now I wish to allow building them in an additional configuration, namely Profile.
We are using the Jenkins CI server and thus the desired configuration is provided through a dedicated Jenkins build parameter DRIVER_PROXY_CONFIG, which is surfaced as an environment variable with the same name.
Now the problem. According to our InstallShield guy, IS cannot use an environment variable in part of a source file path. I quote:
You can use or 'environment variable' or 'user-defined path variables
defined through InstallShield' as file path.
So we can:
Create 'environment variable' for each component (since 'DRIVER_PROXY_CONFIG' is only part of the component path) – not desirable.
Make the 'environment variable' part of the component 'user-defined path variable' – not possible, I have just tried it.
Has anyone done anything like this? The installer depends on multiple source files in different locations, where a part of such a location path is the value of the DRIVER_PROXY_CONFIG environment variable. Note that this part is neither the path prefix nor the suffix.
You absolutely can create it as part of a path. Some exact behaviors do depend on the version of InstallShield, but for the last several you can even use relative parent directories. Just go to the Path Variables view, add a new environment path variable (say Env), and set the environment variable it references. Then either add any number of standard path variables (say Stn) that are defined as <Env>\Sub\Dir, or skip this step and just reference those for the ISBuildSourcePath of the relevant files. Typically adding a file from a path under a defined path variable will use that path variable as part of its path.
If you've already added the files, the convert source paths wizard may help here, but you might find it easier to visit the File table directly to update the ISBuildSourcePath
However there is at least one exception. If your environment variable has the value Sub and your full directory name is SubDirectory, you cannot always reference <Env>Directory. Typically the path variable support will turn that into Sub\Directory instead.
Michael:
What if 'env' is not prefix nor suffix of the path ("SomeDir\<env>\SubDir")?
I have created system env config=release
I have created IS variable 'MyConf' that reference the env 'config'
I have created IS standard path MyPath = "SomeDir\<MyConf>\SubDir"
If I add file from this path - IS won't suggest 'MyPath' as suggested path!!!
The only way I have found, is to add the files, and then visit the File table directly to update the ISBuildSourcePath.
I added the environment variable as a path variable, ytou can set environment variable types here (not string types!)
then you can use that anywhere you'd use a path variable - though I did have to enclose it in square brackets rather than the usual angle ones). It should work in the middle of a path as I have done that with ordinary path variables.