I started a Django 1.7 OpenShift instance. When I have python print all of the paths from sys.path I do not see OPENSHIFT_REPO_DIR (/var/lib/openshift/xxxxx/app-root/runtime/repo).
When I use https://github.com/jfmatth/openshift-django17 to create a project I do see OPENSHIFT_REPO_DIR in the path.
Looking through the example app above I don't see anywhere that this is specifically added to the path. What am I missing?
To clarify:
I have to add the following to my wsgi.py:
import os
import sys
ON_PASS = 'OPENSHIFT_REPO_DIR' in os.environ
if ON_PASS:
x = os.path.abspath(os.path.join(os.environ['OPENSHIFT_REPO_DIR'], 'mysite'))
sys.path.insert(1, x)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
OPENSHIFT_REPO_DIR is not in my path as I would expect. When I used the example git above, I did not have to add anything to the path.
A little while back I had issues with some of the pre-configured OpenShift environment variables not appearing until I restarted my application.
For what its worth, I started up a brand new Django gear, printed the environment variables to the application log, and verified that I do see OPENSHIFT_REPO_DIR (and all other env vars) properly.
This issue appears to be caused by trying to use the standard file structure layout that django produces when you use startproject. Openshift appears to need a flatter file structure. As soon as I moved wsgi up to a sibling of mysite it resolved the issue.
Related
I have a basic ReadTheDocs repository. As per the advice of the build page, I sought to use a .readthedocs.yml to configure it:
Configure your documentation builds! Adding a .readthedocs.yml file to your project is the recommended way to configure your documentation builds. You can declare dependencies, set up submodules, and many other great features.
I added a basic .readthedocs.yml:
version: 2
sphinx:
builder: dirhtml
fail_on_warning: true
and got a build failure:
Problem in your project's configuration. Invalid "sphinx.builder": .readthedocs.yml: Your project is configured as "Sphinx Html" in your admin dashboard, but your "sphinx.builder" key does not match.
This was surprising as it seemed contrary to the guidance in the admin dashboard at https://readthedocs.org/dashboard/PROJECTNAME/advanced/ which led me to assume that I could set whatever I liked in the admin dashboard, but it would be overridden by my .readthedocs.yml (which is the behaviour I expected and wanted):
These settings can be configured using a configuration file. That's the recommended way to set up your project. Settings in the configuration file override the settings listed here.
I updated the setting in the admin dashboard to match the .readthedocs.yml and then got a build error:
Sphinx error:
master file /home/docs/checkouts/readthedocs.org/user_builds/PROJECT_NAME/checkouts/latest/source/contents.rst not found
which looks like https://github.com/readthedocs/readthedocs.org/issues/2569 (RTD not finding Sphinx configuration) - but it's not clear why that's happening because prior to adding .readthedocs.yml, the project built just fine.
I'm struggling to model what's actually going on here:
The config file isn't acting as an "overlay" / "override" onto the web settings - as per the first error, some forms of disagreement are a build failure
It's almost like if the config file exists, the web config is ignored - this would explain the contents.rst issue arising, but this isn't consistent with the first error
Adding a python.install entry to .readthedocs.yml eventually got the site building, but it's still not clear to me if I'm generally doing the right thing, and/or how successful future config changes will be.
The reason you're getting the error is that the sphinx version you're using locally doesn't match with the version readthedocs is using at the time you initiated the build process.
See here: You can use a requirements.txt file to use the same version of sphinx you use locally. I had the same issue. I've solved it by simply adding my version Sphinx==3.1.2
Also, I added a .readthedocs.yml file in my project directory where docs/ resides, pointing to where the conf.py because
I was using an extension sphinxcontrib.napoleon which readthedocs build process fails to recognize.
Wanted readthedocsbuild process to use a specific version on Sphinx.
# .readthedocs.yml
# Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
# Required
version: 1
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: docs/source/conf.py
# Build documentation with MkDocs
#mkdocs:
# configuration: mkdocs.yml
# Optionally build your docs in additional formats such as PDF
formats:
- pdf
# Optionally set the version of Python and requirements required to build your docs
python:
version: 3.7
install:
- requirements: docs/requirements.txt
a
and added all the dependencies needed to generate the documentation in docs/requirement.txt
Babel==2.8.0
imagesize==1.2.0
readme-renderer==26.0
Sphinx==3.1.2
sphinx-argparse==0.2.5
sphinx-rtd-theme==0.5.0
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-images==0.9.2
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-napoleon==0.7
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4
I'm trying to enable vue-devtools in Google Chrome. But I cannot enable it. I'm using vue.js inside the Laravel application.
My server runs using php artisan serve command.
I was seeing the error message in this question's title and this solution worked for me:
Add Vue.config.devtools = true to the file where you create the Vue instance (main.js for me).
Note that, as mentioned in this answer, you need to put the Vue.config.devtools = true line before you create your store in order for the Vuex part of the devtools to work. If you're creating your Vuex store in a separate file (e.g. store.js), you may need to have the Vue.config.devtools = true line in both your main.js file as well as the store.js file.
Below is what the changes looked like in my project:
If the page uses a production/minified build of Vue.js, devtools
inspection is disabled by default so the Vue pane won't show up.
To make it work for pages opened via file:// protocol, you need to
check "Allow access to file URLs" for this extension in Chrome's
extension management panel.
I had to restart the chrome, and it worked :-)
If your using CDN; make sure your not using a production (minified) build of the library.
Use: https://unpkg.com/vue#2.4.4/dist/vue.js
Instead of: https://unpkg.com/vue#2.4.4/dist/vue.min.js
You might need to do Ctrl+Alt+I for it to show up the first time. (Source)
Updated Aug 2022
So apparently as #kissu said, the answer below causes the released code to be an unoptimized one. This might be different than what you want if you want to check production code while being able to check Vue Dev Tools.
Just be aware of it. Unless you don't mind checking the released code in an unoptimized bundle, then the following script is fine. If you don't like the Vue.config.devtools value being static, it might be time to consider env variables or something similar.
Here's how to setup Environtment Variables in Vue
Alternative answer for Vue CLI 3.x
Besides what #NathanWailes has said, this is an alternative which allows the Dev Tools to be available through scripts instead of writing it in your main Vue entry (which is usually main.js or index.js).
You can do this by simply adding this script to package.json
scripts: {
"start:dev": "vue-cli-service build --mode=development"
}
Explanation
This was because Vue.config.devtools are set to false by default in production mode as said by this GitHub Issue. But this has a work around, simply by using --mode=development flag provided in the documentation.
Then you can run using npm run start:dev and check the file in your dist/ folder! ;)
You may use the dev version of vue.js. For example get it here: https://unpkg.com/vue#2.3.2
When using Laravel just make sure you run the proper webpack for your environment for development . Running
npm run watch
should build Vue with debug mode on. Using
npm run production
minifies Vue for production. This will save you having to remember to toggle the debug mode when building for production.
For me Installing latest Vue dev tools - link and enabling 'Allow access to file URLs' in extension settings resolved the issue.
make sure you're running a non-production build of Vue.js. https://github.com/vuejs/vue-devtools/issues/62
Just add into vue.config.js:
module.exports = {
configureWebpack: {
devtool: 'source-map'
}
}
delete package-lock.json, node_modules, run npm i and VueJS Devtool will be working
you could try to set environment variable NODE_ENV to 'development'
(e.g. set NODE_ENV=development on Windows or export NODE_ENV="development" under Linux)
before launching Vue dev server.
In my case for Laravel 9 fresh installation, I forgot to run sail npm run dev.
If you're using Vite you can configure your environment directory via shared options. If you change that and have NODE_ENV set to production you'll receive this message when trying to inspect your app.
I following the instructions in https://www.openshift.com/quickstarts/cherrypy and deployed the sample application successfully.
I made some changes to the wsgi/application file and push the changes. When i ssh in to take a look the changes were made to the application file but when i refresh my page, i still see the old page.
All i did was to change "Hello World!" to "Hello" in wsgi/application.
Any ideas?
Openshift updated the way they do things March 14. Some of the docs and quickstarts are out of date.
I have only used the wsgi server in Cherrypy and not the whole framework itself but the below info may help. You want to place a file called 'app.py' in your root openshift directory. This is the 'entry point' for starting your application. There is also a 'wsgi.py' entry point but I don't think you want that. Take a look at the bug report I posted below to learn more about it.
Here is my app.py
import os
from myapp import my_app
from cherrypy import wsgiserver
if __name__ == '__main__':
ip = os.environ['OPENSHIFT_PYTHON_IP']
port = int(os.environ['OPENSHIFT_PYTHON_PORT'])
app = my_app(global_config=None)
server = wsgiserver.CherryPyWSGIServer((ip, port), app, server_name='myapp Server')
server.start()
You might also want to look at this bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1082363
HTH
Wondering if it's possible to move the module directory in a JBoss 7 install to a non-default loco.
Does anyone know of a config param to specify where to pick it up?
Kinda like a conf-dir, bin-dir type of thing.
Thanks,
Aaron.
Yes, it's actually possible. As the documentation states, from within the standard launch scripts users are able to manipulate the module path by setting the $JBOSS_MODULEPATH environment variable. (If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules). The module path is provided to the running process via the -mp command line argument that is set in the standard scripts.
If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.