for node red, how do you install a node?
I downloaded some code from github that is for node red and placed the contents in this directory:
~/.node-red/node_modules/volttron
Looks like this:
How do I install it, so I can pull the module out of the node red pallet?
The repository you link to includes a readme with instructions for how to install it. Nowhere does it say to copy anything into the node_modules directory.
Step one says:
Copy all files from volttron/examples/NodeRed to your .node-red/nodes
directory.
The instructions included in that directory say to place the files in the ~/.node-red/nodes/volttron directory (you will need to make the nodes dir) not ~/.node-red/node_modules/volttron. But even then it won't work out of the box as it requires the python-shell npm module to also be installed.
A slightly better approach will be to do the following:
Copy the files to ~/.node-red/node_modules/volttron.
In order for Node-RED to locate the nodes in the node_modules directory there must be a package.json file. This also needs to include node-red section listing the nodes.
The package.json also needs to include the required pre-requisite modules in this case python-shell
As a short term work around you can create a package.json in the ~/.node-red/node_modules/volttron directory with the other files and containing the following:
{
"name" : "volttron",
"version" : "0.0.1",
"description" : "A sample node for node-red",
"dependencies": {
"python-shell": "^3.0.1"
},
"keywords": [ "node-red" ],
"node-red" : {
"nodes": {
"volttron": "volttron.js"
}
}
}
Then run npm install while in the volttron directory. You will need to restart Node-RED for the node to be discovered
Related
I am developing a package for a Laravel project on my local machine. I have also spun up a Laravel app so I can manually test the package. My package is located at /home/me/packages/me/my-package and a commit (git) has been tagged with '0.1'.
I want to be able to switch between tagged versions and use specific versions in different projects but having issues.
In my main apps composer file, I am requiring the package like so:
...
"require" : {
"me/my-package" : "0.1"
}
...
"repositories" : [
{
"type": "path",
"url": "/home/me/packages/me/my-package"
}
]
This results in an error:
Problem 1
- Root composer.json requires me/my-package 0.1, found me/my-package[dev-main] but it does not match the constraint.
I have also tried:
"require" : {
"me/my-package" : "dev-main#0.1"
}
(This was an idea taken from How to use a specific tag/version with composer and a private git repository?). This goes through without any errors but:
$ composer show | grep me/my-package
me/my-package dev-main My Package
What is the correct way install a specific version of a package when developing it locally?
Probably the only thing why you hit this message is that you have "type": "path" and not "type": "vcs".
This is that Composer will only refer one version and only one version dev-main. The reason is:
If the package [path repository] is a local VCS repository, the version may be inferred by the branch or tag that is currently checked out. (ref)
You have the main branch checked out at /home/me/packages/me/my-package (/home/me/packages/me/my-package/.git/HEAD content is ref: refs/heads/main and /home/me/packages/me/my-package/.git/refs/heads/main points to the git revision) and composer will only take that one.
You should have no problem to make that change from path to vcs given:
You already have a (git) repository at /home/me/packages/me/my-package (looks so by your question)
You know the absolute path on your local system to that repository (again, looks so by your question: /home/me/packages/me/my-package).
Given these two points, Composer is able to obtain the VCS tagged versions from that path. So basically only the change of the "type":
"repositories" : [
{
"type": "vcs",
"url": "/home/me/packages/me/my-package"
}
]
Just take care that "url" contains the absolute path (and there is a git repository at that place). Likely already all set in your case, just saying.
Git is very prominent that's why I mentioned it here, for other types of VCS Composer also has options at hand. The details - also for git etc. - are available here:
VCS - Repositories (getcomposer.org)
When a build a conda environment like this
conda create --prefix env python=3.6.5
Some absolute paths appear in some json files in the conda-meta folder. How can I avoid it? I just want to use relative paths here or I just want to hide them completely. Is there a way to achieve this? Are they mandatory? See extracted_package_dir, source or package_tarball_full_path attributes:
{
"arch": "x86_64",
"build": "py36_0",
"build_number": 0,
"channel": "https://repo.anaconda.com/pkgs/main/win-64",
"constrains": [],
"depends": [
"python >=3.6,<3.7.0a0"
],
"extracted_package_dir": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"features": "",
"files": [
"Lib/site-packages/certifi-2019.03.09-py3.6.egg-info",
"Lib/site-packages/certifi/__init__.py",
"Lib/site-packages/certifi/__main__.py",
"Lib/site-packages/certifi/__pycache__/__init__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/__main__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/core.cpython-36.pyc",
"Lib/site-packages/certifi/cacert.pem",
"Lib/site-packages/certifi/core.py"
],
"fn": "certifi-2019.3.9-py36_0.tar.bz2",
"license": "ISC",
"link": {
"source": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"type": 1
},
"md5": "e1faa30cf88c0cd141dfe71e70a9597a",
"name": "certifi",
"package_tarball_full_path": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0.tar.bz2",
"paths_data": {
"paths": [
[...]
If I remove the whole folder the environment become useless and I cannot activate it anymore in order to install, update or remove new packages.
I want to do this to encapsulate the environment in one application and I do not want to have my original absolute paths in the computer of the final user.
My Use Case
I am developing an electron app that uses a tornado server (that uses python)
Currently I am using electron-builder to add the environment to the installer and works pretty well, but one drawback is the conda-meta folder I commented above. What I do now is to remove it manually when I want to make an installer.
That will probably break conda. It's not written to treat those as relative paths. If you told us more about your use case, maybe we could help. Are you trying to redistribute an installed environment? Have you see the "constructor" or "conda-pack" projects?
Finally the best solution I found was to ignore the folder when creating the final installer with electron-builder.
So I have applied the directive extraResources to add the conda environment except the folder conda-meta. And I have added the filter "!conda-meta${/*}", the meaning is explained here
Remember that !doNotCopyMe/**/* would match the files in the doNotCopyMe directory, but not the directory itself, so the empty directory would be created. Solution — use macro ${/*}, e.g. !doNotCopyMe${/*}.
The result in the package.json file:
"extraResources": [
{
"from": "../env",
"to": "env",
"filter": [
"**/*",
"!*.pyc",
"!conda-meta${/*}"
]
}
],
I want to use nyc to generate code-coverage. I am building some of my projects into node_modules to use them in other projects. When writing tests I want to test the files inside node_modules and therefore I want to include files from node_modules.
Project-Example-Structure
1. foo (directory)
1.1 bar (directory)
1.1.1 node_modules (directory)
1.1.1.1 someFile.js // I want to include this!
1.1.2 foobar
1.1.2.1 foobar.js // this file works
1.1.3 .nycrc
.nycrc
{
"reporter": [
"html",
"text"
],
"all": true,
"cwd": "../",
"report-dir": "./bar/test-run/coverage",
"include": [
"./bar/**/foobar/*.js",
"./bar/**/node_modules/*.js",
]
}
Execute in terminal
nyc mocha
Explanation
nyc uses the .nycrc. cwd: change-working-directory. I want to be able to include files of parent-directory. Sadly include seems not to be able to use "../".
Inside the include-flag I am specifying which files should be included:
"./bar/foobar/foobar.js" does somehow not work.
But: "./bar/**/foobar/foobar.js" includes foorbar.js.
Expected behaiviour
someFile.js should be included. foorbar.js should be included.
Observed behaiviour
someFile.js is not included. foorbar.js is included.
Environment
MacOS Sierra
nyc 11.8.0
You have to modify your config files with
{
"include": [
"node_modules/**/<fileName>.js"
],
"excludeNodeModules": false
}
Using Koala and started using it by adding the 'css' directory. My directory structure looks like
-- www
-- -- css
-- -- -- template.css
-- -- -- template.scss
I've checked 'compass mode' in Koala but it is giving error 'You must compile individual stylesheets from the project directory'.
I just had this error and resolved it by editing the Koala project settings.
In Koala, right click on your project's folder, follow the menu for Project Settings > New Settings > For SASS
Koala will ask if you want to create a koala-config.json. Answer, yes. Unless this file already exists. In that case go directly to editing it.
Edit the section of koala-config.json called Mappings. Keep in mind that koala-config.json is in the my-project-folder root and the "src" and "dest" values should be relative to that file. So, for me, all my CSS files are in my-project-folder/assets/css and I changed the config file as below:
// The mappings of source directory and output directory
"mappings": [
{
"src": "assets/css",
"dest": "assets/css"
}
],
For you, I suspect this should do it:
// The mappings of source directory and output directory
"mappings": [
{
"src": "www/css",
"dest": "www/css"
}
],
The instructions above did not help me.
SOLUTION: I simply changed the NAME of the FOLDER that held my .scss files from scss to sass, deleted the .rb and .json files (if they exist) and reloaded my file to Koala.
I hope it works for you all.
Check if your computer has Ruby installed. Then set projects paths in Koala as #helgatheviking said
Cucumber.js is supplying a command-line "binary" which is a simple .js file containing a shebang instruction:
#!/usr/bin/env node
var Cucumber = require('../lib/cucumber');
// ...
The binary is specified in package.json with the "bin" configuration key:
{ "name" : "cucumber"
, "description" : "The official JavaScript implementation of Cucumber."
// ...
, "bin": { "cucumber.js": "./bin/cucumber.js" }
// ...
This all works well on POSIX systems. Someone reported an issue when running Cucumber.js on Windows.
Basically, the .js file seems to be executed through the JScript interpreter of Windows (not Node.js) and it throws a syntax error because of the shebang instruction.
My question is: what is the recommended way of setting up a "binary" script that works on both UNIX and Windows systems?
Thanks.
Windows ignores the shebang line #!/usr/bin/env node and will execute it according to the .js file association. Be explicit about calling your script with node
node hello.js
ps. Pedantry: shebangs aren't in the POSIX standard but they are supported by most *nix system.
If you package your project for Npm, use the 'bin' field in package.json. Then on Windows, Npm will install a .cmd wrapper along side your script so users can execute it from the command-line
hello
For npm to create the shim right, the script must have the shebang line #!/usr/bin/env node
your "bin" should be "cucumber" npm will create a "cucumber" or "cucumber.cmd" file pointing to "node %SCRIPTNAME%". the former being for posix environments, the latter being for windows use... If you want the "js" to be part of the executable name... you should use a hyphon instead... "cucumber-js" ... Having a .js file will come before the .js.cmd in your case causing the WScript interpreter to run it as a JScript file, not a node script.
I would suggest looking at coffee-script's package.json for a good example.
{
"name": "coffee-script",
"description": "Unfancy JavaScript",
"keywords": ["javascript", "language", "coffeescript", "compiler"],
"author": "Jeremy Ashkenas",
"version": "1.4.0",
"licenses": [{
"type": "MIT",
"url": "https://raw.github.com/jashkenas/coffee-script/master/LICENSE"
}],
"engines": {
"node": ">=0.4.0"
},
"directories" : {
"lib" : "./lib/coffee-script"
},
"main" : "./lib/coffee-script/coffee-script",
"bin": {
"coffee": "./bin/coffee",
"cake": "./bin/cake"
},
"scripts": {
"test": "node ./bin/cake test"
},
"homepage": "http://coffeescript.org",
"bugs": "https://github.com/jashkenas/coffee-script/issues",
"repository": {
"type": "git",
"url": "git://github.com/jashkenas/coffee-script.git"
},
"devDependencies": {
"uglify-js": ">=1.0.0",
"jison": ">=0.2.0"
}
}
I managed to figure out a solution to a similar issue.
My original plan was to have only one large .js file, for both the API and CLI (the reason is because I didn't know how to share variables between two files at the time). And when everything was built, I tried to add the #!/usr/bin/env node shebang to my file. However that didn't stop Windows Script Host from giving an error.
What I ended up doing was coming up with an idea of a "variable bridge" that allowed variables to be read and set using getVar and setVar. This made me have to extract the CLI code from the API code and add some imports to the variable bridge.
In the CLI file, I added the shebang, and modified the package.json of my project to have:
{
...
"main": "./bin/api.js",
"bin": {
"validator": "./bin/cli.js"
}
...
}
Here are a few small notes that I think might help if Windows Script Host is still giving an error (I applied all of them so I'm not sure which one helped):
Using only LF line endings seemed to help.
It seems that ./bin is the preferred directory for compiled files. I did try ./dist but it didn't work for me.
An empty line after the shebang may be needed:
// cli.js
#!/usr/bin/env node
// code...
Using the same name for main and bin in package.json seemed to be an issue for me.