When I enter django-admin on the command line, I get a list of allowed commands and then an error line:
Note that only Django core commands are listed as settings are not properly configured (error: Requested setting INSTALLED_APPS, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.).
If I try to add a DJANGO_SETTINGS_MODULE environment variable to fix this, I get the message that confit.settings.local is not a valid Python module.
Related
I'm trying to use the modules program to configure my linux computer's environment variables. I add the following command to add environment variables to my bashrc.
module load gcc/5.5
I expect to use the above command to add gcc5.5/bin to $PATH. If I open a new terminal, gcc5.5/bin is in $PATH, but if I use a tmux command, gcc5.5/bin is not added.
I am a newbie to spring-cloud-data-flow. I am following the documentation of Spring Cloud Data Flow (https://dataflow.spring.io/docs/installation/local/docker/). I have downloaded docker-compose.yml file and put it in D:\Dev\spring-cloud-dataflow> directory. When I try to run following commands:
D:\Dev\spring-cloud-dataflow> set DATAFLOW_VERSION=2.1.0.RELEASE
D:\Dev\spring-cloud-dataflow> set SKIPPER_VERSION=2.0.2.RELEASE
D:\Dev\spring-cloud-dataflow> docker-compose up
It gaves me following error:
ERROR: Missing mandatory value for "image" option in service "dataflow-server": DATAFLOW_VERSION is not set!
I am using Powershell, so I tried to use Set-Variable instead of set, but this gave me the same error.
D:\Dev\spring-cloud-dataflow> Set-Variable -Name "DATAFLOW_VERSION" -Value "2.1.0.RELEASE"
D:\Dev\spring-cloud-dataflow> Set-Variable -Name "SKIPPER_VERSION" -Value "2.0.2.RELEASE"
D:\Dev\spring-cloud-dataflow> docker-compose up
ERROR: Missing mandatory value for "image" option in service "dataflow-server": DATAFLOW_VERSION is not set!
I tried the short handed version in the tutorial but did not worked also:
DATAFLOW_VERSION=2.1.0.RELEASE SKIPPER_VERSION=2.0.2.RELEASE docker-compose up
I can see the variables are set:
D:\Dev\spring-cloud-dataflow> echo $DATAFLOW_VERSION
2.1.0.RELEASE
D:\Dev\spring-cloud-dataflow> echo $SKIPPER_VERSION
2.0.2.RELEASE
I could not understand why this error pops up.
Not sure about why it doesn't resolve the variables. Maybe the resolution of the variable doesn't take place in your environment (Windows?).
For the time being, can you set the version values explicitly inside the docker compose yml file and run to see if it sets up correctly?
I've encountered the same issue in windows 10. Set the variables via "Edit the system environment variables" under control panel instead of using "Set" command solved the problem. May help others using windows 10.
#selins_sofa, The PowerShell has a peculiar way for setting environment variables:
$Env:<variable-name> = "<new-value>"
So you should set the DataFlow and Skipper versions like this:
$Env:DATAFLOW_VERSION="2.5.0.BUILD-SNAPSHOT"
$Env:SKIPPER_VERSION="2.4.0.BUILD-SNAPSHOT"
I'm unable to use node-config to get environment variables in Windows.
My index.js is running a CMD with nodemon.
I've open a new CMD and typed set myApp_jwtSecretKey=mySecretHere
// config/custom-environment-variables.json
{
"jwtSecretKey": "myApp_jwtSecretKey"
}
// index.js
console.log(config.get('myApp_jwtSecretKey'))
// I would expect to see 'mySecretHere' but I get an empty string instead
Why is that?
Hi myself from the past!
The reason you are not getting what you'd expect has to do with the set command of Windows.
Using set the variable is limited to the current command line session.
You need to use setx to set variables permanently and so those can share between command line sessions.
In your case, within your CMD, type setx myApp_jwtSecretKey mySecretHere
What exactly is the difference between these two operations?
source activate python3_env && python my_script.py
and
~/anaconda3/envs/python3_env/bin/python my_script.py ?
It appears that activating the environment adds some variables to $PATH, but the second method seems to access all the modules installed in python3_env. Is there anything else going on under the hood?
You are correct, activating the environment adds some directories to the PATH environment variable. In particular, this will allow any binaries or scripts installed in the environment to be run first, instead of the ones in the base environment. For instance, if you have installed IPython into your environment, activating the environment allows you to write
ipython
to start IPython in the environment, rather than
/path/to/env/bin/ipython
In addition, environments may have scripts that add or edit other environment variables that are executed when the environment is activated (see the conda docs). These scripts can make arbitrary changes to the shell environment, including even changing the PYTHONPATH to change where packages are loaded from.
Finally, I wrote a very detailed answer of what exactly is happening in the code over there: Conda: what happens when you activate an environment? That may or may not still be up-to-date though. The relevant part of the answer is:
...the build_activate method adds the prefix to the PATH via the _add_prefix_to_path method. Finally, the build_activate method returns a dictionary of commands that need to be run to "activate" the environment.
And another step deeper... The dictionary returned from the build_activate method gets processed into shell commands by the _yield_commands method, which are passed into the _finalize method. The activate method returns the value from running the _finalize method which returns the name of a temp file. The temp file has the commands required to set all of the appropriate environment variables.
Now, stepping back out, in the activate.main function, the return value of the execute method (i.e., the name of the temp file) is printed to stdout. This temp file name gets stored in the Bash variable ask_conda back in the _conda_activate Bash function, and finally, the temp file is executed by the eval Bash function.
So you can see, depending on the environment, running conda activate python3_env && python my_script.py and ~/anaconda3/envs/python3_env/bin/python my_script.py may give very different results.
I have a rails application that I set to use a proxy so that I could update gems in my school's LAN.
However now that I'm not using the school's network, when I do
bundle install
I get this error
Unfortunately, a fatal error has occurred. Please see the Bundler
troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!
/home/me/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/uri/generic.rb:214:in `initialize': the scheme http does not accept registry part: cavs#students:cavsuon#proxy.uonbi.ac.ke:80 (or bad hostname?) (URI::InvalidURIError)
When I also do
gem update bundler
or
gem update --system
I get this error
ERROR: While executing gem ... (URI::InvalidURIError)
the scheme https does not accept registry part: cavs#students:cavsuon#proxy.uonbi.ac.ke:80 (or bad hostname?
I cannot recall how I set up my app to use proxy but even when I did it has never worked so I thought that it was never using a proxy in the first place.
How can I unset this proxy configuration and set it again if I'm on my school's network
Upon doing
echo $http_proxy
as suggested, I get
http://cavs#students:cavsuon#proxy.uonbi.ac.ke:80
How do I unset $http_proxy
By default it may be picking up the http_proxy environment variable.
Try running
echo $http_proxy
on the command line to see what it gives back to you. You can set that value using
export http_proxy=http://user:password#host:port
If that doesn't work, also see what HTTP_PROXY is set to.
You can unset a variable temporarily by using unset http_proxy. If it is something you need to change more permanently (i.e. it is there every time you open a terminal) you will need to check the various hidden files in your home directory (i.e. .profile or .bashrc) to find and remove it.
I had similar problem which turned out to be the problem in Ruby itself:
The problem is related to the uri component of Ruby itself, which
tries to match the userinfo part of the URI
So, in your case, according to this regexp doesn't accept # character and you should modify your /usr/lib/ruby/1.8/uri/common.rb:
-ret[:USERINFO] = userinfo = "(?:[#{unreserved};:&=+$,]|#{escaped})*"
+ret[:USERINFO] = userinfo = "(?:[#{unreserved};:&=+$,#]|#{escaped})*"
run export http_proxy=http://x.x.x.x:8080 on the command line and then check if that has changed using echo $http_proxy. This worked for me on 12/18/2018