I cloned a rails project from github and trying to run rails generate rspec:install after running bundle install. The console gives following
`Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
# Default: /Users/sankethpurwar/.rvm/rubies/ruby-2.3.1/bin/ruby
-m, [--template=TEMPLATE] # Path to some application template (can be a filesystem path or URL)
[--skip-gemfile], [--no-skip-gemfile] # Don't create a Gemfile
-B, [--skip-bundle], [--no-skip-bundle] # Don't run bundle install
-G, [--skip-git], [--no-skip-git] # Skip .gitignore file
[--skip-keeps], [--no-skip-keeps] # Skip source control .keep files
-O, [--skip-active-record], [--no-skip-active-record] # Skip Active Record files
-S, [--skip-sprockets], [--no-skip-sprockets] # Skip Sprockets files
-d, [--database=DATABASE] # Preconfigure for selected database (options: mysql/oracle/postgresql/sqlite3/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)
# Default: sqlite3
-j, [--javascript=JAVASCRIPT] # Preconfigure for selected JavaScript library
# Default: jquery
-J, [--skip-javascript], [--no-skip-javascript] # Skip JavaScript files
[--dev], [--no-dev] # Setup the application with Gemfile pointing to your Rails checkout
[--edge], [--no-edge] # Setup the application with Gemfile pointing to Rails repository
-T, [--skip-test-unit], [--no-skip-test-unit] # Skip Test::Unit files
[--rc=RC] # Path to file containing extra configuration options for rails command
[--no-rc], [--no-no-rc] # Skip loading of extra configuration options from .railsrc file
Runtime options:
-f, [--force] # Overwrite files that already exist
-p, [--pretend], [--no-pretend] # Run but do not make any changes
-q, [--quiet], [--no-quiet] # Suppress status output
-s, [--skip], [--no-skip] # Skip files that already exist
Rails options:
-h, [--help], [--no-help] # Show this help message and quit
-v, [--version], [--no-version] # Show Rails version number and quit
Description:
The 'rails new' command creates a new Rails application with a default
directory structure and configuration at the path you specify.
You can specify extra command-line arguments to be used every time
'rails new' runs in the .railsrc configuration file in your home directory.
Note that the arguments specified in the .railsrc file don't affect the
defaults values shown above in this help message.
Example:
rails new ~/Code/Ruby/weblog
This generates a skeletal Rails installation in ~/Code/Ruby/weblog.
See the README in the newly created application to get going.`
Do I need to do any additional setup to work with an existing code base?
I think you are not running generator command from project directory. go to your project directory then run the command. If bundler in not installed then run gem install bundler after that run bundle install
Related
I am bundling using Webpack 4.
I have multiple Webpack configurations exported in webpack.config.js.
First configuration is to bundle lient code targeting browsers.
Second configuration is to bundle server code targeting node.
I am specifying these browsers and node targets using browserslist in package.json.
I need to specify different browserslists for client and server bundles, but I only have one browserslist key in package.json.
How can I specify different browserslists using package.json?
You don't have to use package.json. If you create a file called .browserslistrc or browserslist at the root of your project, you can use a different configuration.
# Any general config goes at the very top, above any section headers
# ...
# Put section headers in [brackets]
[node]
supports es6-modules
[web]
>1% and not dead
Then call webpack and set BROWSERSLIST_ENV:
BROWSERSLIST_ENV=dev webpack -c webpack.dev.js # Build development
BROWSERSLIST_ENV=prod webpack -c webpack.prod.js # Build production
Your webpack command may be different depending on your configuration.
I am learning pktgen based on DPDK. There is no problem during the DPDK's process(for example, installation, allocating large pages, binding NICs, running DPDK sample programs, etc.). I follow Getting Started with Pktgen and when I run run.py it shows an empty list of config files. Then I try to execute the instructions on the doc, I get an error says "Config file 'default' not found".
root#ubuntu:/home/chang/pktgen-dpdk/tools# ./run.py
>>> sdk '/home/chang/dpdk', target 'x86_64-native-linuxapp-gcc'
*** Pick one of the following config files
Configurations:
Name - Description
---- -----------
root#ubuntu:/home/chang/pktgen-dpdk/tools# ./run.py -s default
>>> sdk '/home/chang/dpdk', target 'x86_64-native-linuxapp-gcc'
*** Config file 'default' not found
Configurations:
Name - Description
---- -----------
root#ubuntu:/home/chang/pktgen-dpdk/tools#
But in fact, the configuration file does exist in /pktgen-dpdk/cfg
root#ubuntu:/home/chang/pktgen-dpdk/cfg# ls
bond.cfg default.cfg pktgen-1.cfg server_mif.cfg
client_memif.cfg half-bond.cfg pktgen-2.cfg
client_mif.cfg many-cores.cfg server_memif.cfg
My system is Ubuntu 18.04 installed on VMware. I tried to re-clone the code, re-compile dpdk and pktgen, tried to install it on another machine, but got the same error.
Thanks in advance!
Looks like we have to run the script from the main project directory, i.e. do cd .. and try again. Here is the quote from the README.md
Using the new tools/run.py script to setup and run pktgen with different configurations. The configuration files are located in the cfg directory with filenames ending in .cfg.
To use a configuration file;
$ ./tools/run.py -s default # to setup the ports and attach them to DPDK (only needed once per boot)
$ ./tools/run.py default # Run the default configuration
I want to have a manifest in my ember app, because I want to use it on mobile devices and have some offline capabilities.
I have found the plugin ember-cli-deploy-manifest:
https://github.com/ember-cli-deploy/ember-cli-deploy-manifest
It is well documented in the readme and looked promising.
But how do I use the plugin?
I have installed it using this command:
ember install ember-cli-deploy-manifest
I build my app using this command:
ember build -prod
No manifest is created. I am probably missing some simple step, but can't figure it out. How do I tell ember build to use the plugin?
UPDATE
I followed the suggestion in the comment of the answer below. I dropped using the manifest-plugin and created a manifest file manually. Then the challenge is to get proper fingerprinted filenames in the manifest file.
In my ember-cli-build.js file I have:
module.exports = function(defaults) {
var app = new EmberApp(defaults, {
fingerprint: {
exclude: [],
extensions: ['js', 'css', 'png', 'jpg', 'gif', 'map'],
replaceExtensions: ['html','css','js', 'appcache']
}
});
...
My manifest file is called eea.appcache and is located in the /public folder. It is copied to the dist-folder during build.
However the content of the file (the list of filenames) are not fingerprinted. Filenames in the other files (html, css, js) are fingerprinted correctly.
Here is my public/eea.appcache:
CACHE MANIFEST
# 2016-03-15
# V 1.0
CACHE:
index.html
assets/vendor.css
assets/eea.css
assets/vendor.js
assets/eea.js
assets/img/Icon120x120.png
My buildstep is still:
ember build -prod
How to get the filenames in the manifets files updated with the MD5 fingerprint?
The ember-cli-deploy-manifest is for use with ember-cli-deploy.
So you need to run ember deploy -production once you have installed ember deploy.
Install ember-cli-deploy
ember install ember-cli-deploy
Then
ember deploy -production
I finally got it to work, but this solution is really hack'ish.
I figured this out by trial and error.
The broccoli-assets-rev has some tricky rules when it parses a file to find the filenames. The format that are normally used in a manifest file the filenames are not found by the parser.
But if the files are listed in the comments of the file with quotes and correct path is used, it will work.
If the manifest file is located in the root of the public folder it will end up in the root of the webpage. Then the paths will be as below.
My file looks like this:
CACHE MANIFEST
# 2016-03-15
# V 1.1
# '
# 'assets/vendor.css'
# 'assets/eea.css'
# 'assets/vendor.js'
# 'assets/eea.js'
# 'assets/img/Icon120x120.png'
CACHE:
index.html
assets/vendor.css
assets/eea.css
assets/vendor.js
assets/eea.js
assets/img/Icon120x120.png
NETWORK
*
Then the resulting built file looks like this:
CACHE MANIFEST
# 2016-03-15
# V 1.1
#
# 'assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css'
# 'assets/eea-ddacde3bdf32d3f94c5a01a2054c6f72.css'
# 'assets/vendor-3229c2c849c3d52c0b362d9fee2106ad.js'
# 'assets/eea-4c760118f51f7402db2f0b6074b6960b.js'
# 'assets/img/Icon120x120-40b31b55211fb293dedf556a648aa47e.png'
CACHE:
index.html
assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css
assets/eea-ddacde3bdf32d3f94c5a01a2054c6f72.css
assets/vendor-3229c2c849c3d52c0b362d9fee2106ad.js
assets/eea-4c760118f51f7402db2f0b6074b6960b.js
assets/img/Icon120x120-40b31b55211fb293dedf556a648aa47e.png
NETWORK
*
I'm just having a bit of trouble understanding why this command:
>appcfg.py -A adept-box-109804 update app.yaml
as given by the Try Google App Engine Now page does not work. I have downloaded the App Engine SDK for Python, and have Path set up to point to the location of appcfg.py, but running appcfg.py in my projects root directory does not work in the command line. I either have to navigate to the folder containing appcfg.py and do
>python appcfg.py help
or do
>python "C:\Program Files (x86)\Google\google_appengine\appcfg.py" help
to get a command to work from anywhere. I used the latter method to deploy my test app, but was just wondering if someone could explain why the command as given by the simple Google tutorial did not do anything. I also checked to make sure that .py files are automatically opened with the Python 2.7 interpreter, such that a file hello.py will be executed in the command line by simply typing
>hello.py
and it will output its print statement. On the other hand, using appcfg.py in a similar manner gives the same output no matter the arguments (please note I truncated the output, but rest assured that they are identical no matter the arguments:
C:\>appcfg.py help backends
Usage: appcfg.py [options] <action>
Action must be one of:
backends: Perform a backend action.
backends configure: Reconfigure a backend without stopping it.
backends delete: Delete a backend.
backends list: List all backends configured for the app.
backends rollback: Roll back an update of a backend.
backends start: Start a backend.
backends stop: Stop a backend.
backends update: Update one or more backends.
create_bulkloader_config: Create a bulkloader.yaml from a running application.
cron_info: Display information about cron jobs.
delete_version: Delete the specified version for an app.
download_app: Download a previously-uploaded app.
download_data: Download entities from datastore.
help: Print help for a specific action.
list_versions: List all uploaded versions for an app.
request_logs: Write request logs in Apache common log format.
resource_limits_info: Get the resource limits.
rollback: Rollback an in-progress update.
set_default_version: Set the default (serving) version.
start_module_version: Start a module version.
stop_module_version: Stop a module version.
update: Create or update an app version.
update_cron: Update application cron definitions.
update_dispatch: Update application dispatch definitions.
update_dos: Update application dos definitions.
update_indexes: Update application indexes.
update_queues: Update application task queue definitions.
upload_data: Upload data records to datastore.
vacuum_indexes: Delete unused indexes from application.
Use 'help <action>' for a detailed description.
C:\>appcfg.py help update
Usage: appcfg.py [options] <action>
Action must be one of:
backends: Perform a backend action.
backends configure: Reconfigure a backend without stopping it.
backends delete: Delete a backend.
backends list: List all backends configured for the app.
backends rollback: Roll back an update of a backend.
backends start: Start a backend.
backends stop: Stop a backend.
backends update: Update one or more backends.
create_bulkloader_config: Create a bulkloader.yaml from a running application.
cron_info: Display information about cron jobs.
delete_version: Delete the specified version for an app.
download_app: Download a previously-uploaded app.
download_data: Download entities from datastore.
help: Print help for a specific action.
list_versions: List all uploaded versions for an app.
request_logs: Write request logs in Apache common log format.
resource_limits_info: Get the resource limits.
rollback: Rollback an in-progress update.
set_default_version: Set the default (serving) version.
start_module_version: Start a module version.
stop_module_version: Stop a module version.
update: Create or update an app version.
update_cron: Update application cron definitions.
update_dispatch: Update application dispatch definitions.
update_dos: Update application dos definitions.
update_indexes: Update application indexes.
update_queues: Update application task queue definitions.
upload_data: Upload data records to datastore.
vacuum_indexes: Delete unused indexes from application.
Use 'help <action>' for a detailed description.
I finally tracked down the real reason, and it wasn't a bug with the AppEngine SDK. Rather it was with my Python interpreter, as I noticed it wasn't accepting arguments for any .py files. It turned out to be a registry error, located at [HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command] where I had to change the value from "C:\Python27\python.exe" "%1" to "C:\Python27\python.exe" "%1" %*
How this happened, whether it be the Python 2.7 installer, or maybe the AppEngine SDK, I'm not sure though.
Your confusion probably stems from mixing up 2 possible invocations styles:
python appcfg.py ...
appcfg.py ...
The 1st one can't make use of the fact that the location of the appcfg.py is in the path, it is just an argument to the python executable, which can not locate the appcfg.py file unless either:
it finds it in the current directory
the appcfg.py file is specified using a full path or a path relative to the current working directory from which python is invoked
This is the reason for which your 2nd and 3rd commands don't work as you'd expect. Using the 2nd invocation style instead should work if the location of the appcfg.py is in the path - just as your last command invocation does.
Key point to remember: the path configuration applies to the command executable only, not to its arguments (which BTW each executable may process as it wishes, some executables may combine arguments with the path configuration to obtain location of files).
Similarly appcfg.py itself (once successfully invoked using either of the 2 invocation styles) needs to be able to locate your app.yaml file specified as argument. It cannot do so unless either:
it finds it in the current directory
the app.yaml file (or its directory) is specified using a full path or a path relative to the current working directory from which appcfg.py is invoked
I suspect appcfg.py's inability to locate your app.yaml file may be the reason for which the 1st command you mentioned didn't work. If not you should provide details about the failure.
Regarding why the output of your last command is identical regardless of the arguments, I'm not sure, it could be a bug in the windows version of the SDK. In linux the output is different:
> appcfg.py help backends
Usage: appcfg.py [options] backends <directory> <action>
Perform a backend action.
The 'backends' command will perform a backends action.
Options:
-h, --help Show the help message and exit.
-q, --quiet Print errors only.
-v, --verbose Print info level logs.
--noisy Print all logs.
-s SERVER, --server=SERVER
The App Engine server.
-e EMAIL, --email=EMAIL
The username to use. Will prompt if omitted.
-H HOST, --host=HOST Overrides the Host header sent with all RPCs.
--no_cookies Do not save authentication cookies to local disk.
--skip_sdk_update_check
Do not check for SDK updates.
-A APP_ID, --application=APP_ID
Set the application, overriding the application value
from app.yaml file.
-M MODULE, --module=MODULE
Set the module, overriding the module value from
app.yaml.
-V VERSION, --version=VERSION
Set the (major) version, overriding the version value
from app.yaml file.
-r RUNTIME, --runtime=RUNTIME
Override runtime from app.yaml file.
-E NAME:VALUE, --env_variable=NAME:VALUE
Set an environment variable, potentially overriding an
env_variable value from app.yaml file (flag may be
repeated to set multiple variables).
-R, --allow_any_runtime
Do not validate the runtime in app.yaml
--oauth2 Ignored (OAuth2 is the default).
--oauth2_refresh_token=OAUTH2_REFRESH_TOKEN
An existing OAuth2 refresh token to use. Will not
attempt interactive OAuth approval.
--oauth2_access_token=OAUTH2_ACCESS_TOKEN
An existing OAuth2 access token to use. Will not
attempt interactive OAuth approval.
--authenticate_service_account
Authenticate using the default service account for the
Google Compute Engine VM in which appcfg is being
called
--noauth_local_webserver
Do not run a local web server to handle redirects
during OAuth authorization.
I had this problem, and is deepened in local variable python version that different from app engine python version.
So the solution is just to add before the script the current python version location:
C:\Python27\python.exe "C:\Program Files (x86)\Google\google_appengine\appcfg.py"
And it just return to work well.
I am trying to switch Jetty from 7.6 to 9.2.
I read and understood that "OPTION" will no more work. So I changed my command from
java -jar start.jar --ini **OPTIONS**=server,jmx,resources,websocket,ext,plus,jsp,annotations /u/khandela/project/base//etc/config/cometd/cometd_jetty_config.xml
to
start.jar --ini **--module**=server,jmx,resources,websocket,ext,plus,jsp,annotations /u/khandela/project/base//etc/config/cometd/cometd_jetty_config.xml
But I got below warning:
WARNING: ** Unable to continue, required dependency missing. [jsp-impl/${jsp-impl}-jsp]
WARNING: ** As configured, Jetty is unable to start due to a missing enabled module dependency.
WARNING: ** This may be due to a transitive dependency akin to spdy on npn, which resolves based
How to resolve it ?
The error you are seeing about [jsp-impl/${jsp-impl}-jsp] is because a default jsp implementation was not defined when you requested startup of Jetty.
Jetty 9.2.x has 2 different core JSP engines available.
apache - the Apache Jasper JSP engine (the new Jetty default)
glassfish - the Glassfish Jasper JSP engine (original version in use by Jetty. Now obsolete / buggy and deprecated)
The behavior in Jetty 9.2 was to force users to decide which implementation they want to use.
This was a mistake and just confuses users that want to start jetty in their own way (ie: not using the start.ini or ${jetty.base} documented mechanisms)
A feature request was filed, and the next release of Jetty after 9.2.1 will apply defaults for this value. With autoselection for apache.
In the meantime, while you wait for Jetty 9.2.2 (or 9.3.0), add a property defining which jsp-impl you want to use.
$ start.jar --module=server,jmx,resources,websocket,ext,plus,jsp,annotations
jsp-impl=apache
/u/khandela/project/base/etc/config/cometd/cometd_jetty_config.xml
Note: get rid of --ini as that is not used by start.jar
I had similar problem in Netbeans 8.0 to start Jetty 9.2.1. After creating JettyServer Jetty started, when I added into actual Jetty Base Locationin to start.ini jsp-impl=apache clause.
There is complete listing start.ini:
#===========================================================
# Jetty start.jar arguments
#
# The contents of this file, together with the *.ini
# files found in start.d directory are used to build
# the classpath and command line on a call to
# java -jar start.jar [arg...]
#
# Use the following command to see more options
# java -jar start.jar --help
#
# Each line in these files is prepended to the command line
# as arguments and may be either:
# + A property like: name=value
# + A module to enable like: --module=jmx
# + An XML configuration file like: etc/jetty-feature.xml
# + A start.jar option like: --dry-run
#
# If --exec or --dry-run are used, then this file may also
# contain lines with:
# + A JVM option like: -Xmx2000m
# + A System Property like: -Dcom.sun.management.jmxremote
#
# The --add-to-start=module option can be used to append
# a configuration template for a module to start.ini
# The --add-to-startd=module option can be used to create
# a configuration template for a module in start.d/module.ini
# For example configure and run with SPDY use
#
# java -jar start.jar --add-to-startd=spdy
# $EDITOR start.d/spdy.ini
# java -jar start.jar
#
#===========================================================
#
# Initialize module server
#
#--module=server
--module=server,websocket,jsp,ext,jmx,resources,plus,annotations,commandmanager
# removes bug
jsp-impl=apache
## Server Threading Configuration
# minimum number of threads
threads.min=10
# maximum number of threads
threads.max=200
# thread idle timeout in milliseconds
threads.timeout=60000
# What host to listen on (leave commented to listen on all interfaces)
#jetty.host=myhost.com
# Dump the state of the Jetty server, components, and webapps after startup
jetty.dump.start=false
# Dump the state of the Jetty server, before stop
jetty.dump.stop=false
#
# Initialize module deploy
#
--module=deploy
#
# Initialize module websocket
#
#--module=websocket
#
# Initialize module jsp
#
#--module=jsp
# JSP Configuration
# To use an non-jdk compiler for JSP compilation uncomment next line
# -Dorg.apache.jasper.compiler.disablejsr199=true
#
# Initialize module ext
#
#--module=ext
#
# Initialize module resources
#
#--module=resources
#--module=commandmanager
By comparing original start.ini file, you cas see differences.