I am trying to use grunt on my new windows 8 machine, which is not working. Here's the problem.
c:\Users\User\Documents\Source\Project>npm install -g grunt
grunt#0.4.5 C:\Users\User\AppData\Roaming\npm\node_modules\grunt
├── dateformat#1.0.2-1.2.3
├── eventemitter2#0.4.14
├── which#1.0.5
├── getobject#0.1.0
├── colors#0.6.2
├── rimraf#2.2.8
├── async#0.1.22
├── hooker#0.2.3
├── grunt-legacy-util#0.2.0
├── exit#0.1.2
├── lodash#0.9.2
├── coffee-script#1.3.3
├── underscore.string#2.2.1
├── iconv-lite#0.2.11
├── grunt-legacy-log#0.1.1 (underscore.string#2.3.3, lodash#2.4.1)
├── nopt#1.0.10 (abbrev#1.0.5)
├── glob#3.1.21 (inherits#1.0.0, graceful-fs#1.2.3)
├── minimatch#0.2.14 (sigmund#1.0.0, lru-cache#2.5.0)
├── findup-sync#0.1.3 (lodash#2.4.1, glob#3.2.11)
└── js-yaml#2.0.5 (esprima#1.0.4, argparse#0.1.15)
c:\Users\User\Documents\Source\Project>grunt
'grunt' is not recognized as an internal or external command,
operable program or batch file.
I'm trying to look for grunt.cmd which I cannot find anywhere in my system. Is somebody else facing this problem too?
Try installing grunt-cli and see if that fixes your problem:
npm install -g grunt-cli
Related
I have to work on a shared Airflow 1.10 project, so I have cloned the repository and the structure is as follow:
airflow
├── airflow.cfg
├── airflow.db
├── dags
│ ├── dags_here.py
│
├── dags_conf
│ ├── some settings for dags
│ │ └── settings.py
│ │ ├── __init__.py
│ │ ├── settings.py
│ │ └── todo.txt
| |__ init.py
|
├── utilities
│ ├── __init__.py
│ └── some_name
│ ├── airflow
│ │ └── hooks.py
└── sensors.py
└── plugins.py
│ ├── common
│ │ ├some_other_code_files.py
│ ├── __init__.py
|
├── README.md
├── unittests.cfg
└── venv
├── lib64 -> lib
└── pyvenv.cfg
But when I try to list dags I face this error:
plugins_manager.py:225} ERROR - No module named 'common' Traceback
(most recent call last): File
"/home/xxx/venv/lib/python3.8/site-packages/airflow/plugins_manager.py",
line 218, in
m = imp.load_source(namespace, filepath) File "/usr/lib/python3.8/imp.py", line 171, in load_source
module = _load(spec) File "", line 702, in _load File "", line 671, in
_load_unlocked File "", line 783, in exec_module File "", line 219,
in _call_with_frames_removed File
"/home/xxx/airflow/utilities/xxx/common/insert_obj.py", line 3, in
from common.xxxxx import Class_name ModuleNotFoundError: No module named 'common' [2021-05-30 23:13:05,933] {plugins_manager.py:226}
ERROR - Failed to import plugin
/home/xxxx/airflow/utilities/xxxxx/common/dag_file.py
I have tried below configs inside may airflow.cfg but always the same error:
plugins_folder=/home/xxx/airflow/utilities
Adding a parent directory inside Airflow folder called plugins with an __init__.py file and copying utilities inside that:
plugins_folder=/home/xxx/airflow/plugins
confirm how the environment variables that Airflow uses or the airflow.cfg settings are configured.
environment variables
AIRFLOW_HOME=<YOUR_PROJ>
AIRFLOW__CORE__DAGS_FOLDER=$AIRFLOW_HOME/dags
AIRFLOW__CORE__PLUGINS_FOLDER=$AIRFLOW_HOME/utilities
airflow.cfg
dags_folder = {AIRFLOW_HOME}/dags
plugins_folder = {AIRFLOW_HOME}/utilities
Also, see what is configured in PYTHONPATH:
import sys
from pprint import pprint
pprint(sys.path)
# [
# '/ssddisk/project_name/dags',
# '/ssddisk/project_name/config',
# '/ssddisk/project_name/utilities',
# ...
# ]
See documentation for more details: https://airflow.apache.org/docs/apache-airflow/stable/howto/custom-operator.html#creating-a-custom-operator
I have a typo3 extension (created with extension manager) and it seems no matter what I try I always get the following error:
Class CM\Parser\Controller\ParserController does not exist. Reflection failed.
I used the explanations for this problem TYPO3 tutorial extension, controller does not exist and "Controller does not exist. Reflection failed." TYPO3. Neither of them seem to work.
My composer.json in the root directory has the following entry:
"autoload": {
"psr-4": {
"CM\\parser\\": "./packages/cm-parser/Classes"
}
}
My typo3conf/ext folder has a symlink on packages/cm-parser. My composer.json inside the extension directory (packages/cm-parser) has the entry:
"autoload": {
"psr-4": {
"CM\\parser\\": "./Classes"
}
}
Thanks in advance for any help.
My directory structure looks like this (starting in /opt/lampp/htdocs/my-new-project) which is a typo3 v9.5 installation
> .
├── packages
│ └── cm-parser
│ ├── Classes
│ ├── Configuration
│ ├── Documentation.tmpl
│ ├── Resources
│ └── Tests
├── public
│ ├── fileadmin
│ │ ├── _processed_
│ │ ├── _temp_
│ │ └── user_upload
│ ├── typo3
│ │ └── sysext
│ ├── typo3conf
│ │ ├── ext
│ │ └── l10n
│ ├── typo3temp
│ │ ├── assets
│ │ └── var
│ └── uploads
│ └── tx_extensionbuilder
├── var
...
In my typo3conf/ext directory there is a symlink called parser to packages/cm-parser (I think the composer created that for me).
So I hope this symlink works for Typo3.
The files ext_emconf.php and ext_localconf.php are also in the right place. The folder structure above only displays my folders (tree -L 3) up to the third level.
The controller class is CM\Parser\Controller\ParserController, while in your composer.json you're using CM\\parser\\ (with a lowercase p) in the PSR4 autoload. This should be CM\\Parser\\
After changing this you need to of course run composer dumpautoload to reload the autoload information.
In your root composer.json file:
➊ You do not need the PSR-4 autoload section for "CM\\parser\\".
➋ You possibly have to add the path to packages/* as a repository.
➌ You have to include the composer namespace of your extension.
In your file system:
➍ You do not need typo3conf/ext/ as a symbolic link to packages/.
Try the following changes:
In your root composer.json file, remove the PSR-4 autoload section as outlined above. Add the packages/ directory as a path under repositories. For example:
{
"repositories": [
{
"type": "composer",
"url": "https://composer.typo3.org/"
},
{
"type": "path",
"url": "packages/*"
}
],
...
}
Store your extension code in the following path: packages/parser/.
Assuming your extension key reads parser and your vendor name is CM, the composer namespace becomes cm/parser. Add this as a requirement to the composer config file. You can use the following command on the command line:
composer require cm/parser:dev-master
This assumes, that packages/parser/ is a valid Git repository and has the master branch (do not use a version in the extension's composer.json file).
If the local Git repository and version (in the example above: dev-master) can be found, composer will automatically install all dependencies as required and it will create a symbolic link:
typo3conf/ext/parser -> ../../../packages/parser/
Also double check if all PHP files show the correct PHP namespace: CM\Parser\... and your controller class name reads ParserController.
If you can share your TYPO3 extension code, upload it to GitHub (or any other place) and share the link here. This way people can review your code and possibly spot further errors.
To make Artifactory as self-service as possible for our users, giving permissions to users to deploy to parts of repositories using their personal or team accounts, I'm trying to figure out how to configure this.
For readable directory structure based repositories like anything in the java world, the Permission Targets work perfectly (https://www.jfrog.com/confluence/display/RTF/Managing+Permissions). But I can't find any docs on how to use this for non-human-predicatable/readable directory structures, like PIP, or the flat directory structure, like NPM.
In the java world, repositories have a nicely structured tree like:
~/.m2/repository$ tree org/ | head -20
org/
├── antlr
│ ├── antlr4-master
│ │ └── 4.7.1
│ │ ├── antlr4-master-4.7.1.pom
│ │ ├── antlr4-master-4.7.1.pom.sha1
│ │ └── _remote.repositories
│ └── antlr4-runtime
│ └── 4.7.1
│ ├── antlr4-runtime-4.7.1.jar
│ ├── antlr4-runtime-4.7.1.jar.sha1
│ ├── antlr4-runtime-4.7.1.pom
│ ├── antlr4-runtime-4.7.1.pom.sha1
│ └── _remote.repositories
├── apache
│ ├── ant
│ │ ├── ant
│ │ │ ├── 1.10.1
│ │ │ │ ├── ant-1.10.1.jar
│ │ │ │ ├── ant-1.10.1.jar.sha1
For example, to give teamantl permission to only read, annotate, and write to org/antlr/antlr4-master/**, the following json can be PUT to Artifactory REST API (PUT /api/security/permissions/{permissionTargetName})
{
"includesPattern": "org/antlr/antlr4-master/**",
"repositories": [
"libs-release-local",
"libs-snapshot-local"
],
"principals": {
"groups" : {
"teamantl": ["r","n","w"]
}
}
}
But for example a pip repo is completely hashed:
Which is completely useless in the permission target "includesPattern".
How should this (Permission Targets) work for repo's like PIP, and NPM?
Your screenshot shows a virtual PyPI repo, which is generated and thus hash-structured.
Normally, these are backed by physical repos, filled using twine upload and thus having a ‹pkg›/‹version›/‹file› structure – i.e. perfectly usable as permission targets with package granularity.
I would like to present the output of a tree command in a Restructured Text document. I am using this code:
.. code-block:: bash
project
├── demo.py
├── LICENCE.txt
├── processes
│ ├── area.py
│ └── bboxinout.py
├── pywps.cfg
├── requirements.txt
├── server.py
├── setup.py
├── static
├── templates
└── tests
Which is producing the following output:
I then tried to replace the tree characters with unicode definitions, such as:
.. |hbar| unicode:: 01C0 ..
But the |hbar| sequence is printed verbatim when used inside a code block.
Is there any other way to force these characters to be printed correctly?
In ReST, I use literal blocks to represent tree structures:
::
project
├── demo.py
├── LICENCE.txt
├── processes
│ ├── area.py
│ └── bboxinout.py
├── pywps.cfg
├── requirements.txt
├── server.py
├── setup.py
├── static
├── templates
└── tests
I hope this helps!
A bit too late to answer your question now, but for anyone coming across this question, I managed to display a tree by using line blocks, i.e. adding "| " at the start of every line, as such:
| project
| ├── demo.py
| ├── LICENCE.txt
| ├── processes
| │ ├── area.py
| │ └── bboxinout.py
| ├── pywps.cfg
| ├── requirements.txt
| ├── server.py
| ├── setup.py
| ├── static
| ├── templates
| └── tests
And when you make your html, this should give you something like this:
It's not perfect and it does not wrap the tree in a block, but does show the tree.
Hope this helps.
I'm porting an application from php to node(sailsjs) at the same time trying to replace ant with grunt. I like the current project build structure and I would like to preserve some of it.
It looks like below...
project root
├── build (git ignored)
│ ├── coverage
│ ├── dist(to be deployed to target env)
│ └── local(to be deployed to local env)
├── lib
│ └── some library files like selenium..etc.
├── src
│ ├── conf
│ │ └── target/local properties
│ ├── scripts(may not be needed with grunt??)
│ │ ├── db
│ │ │ └── create_scripts...
│ │ ├── se
│ │ │ └── run_selenium_scripts...
│ │ └── tests
│ │ └── run_unit_test_scripts...
│ ├── tests
│ │ └── test_code....
│ └── webapp(this is where I'd like to place node[sailsjs] code)
│ └── code....
└── wiki .etc...
It doesn't exactly have to be the same way as above but more or less I prefer to build something similar. Now, pretty much all the sailsjs examples I have seen look like below.
project root
├── .tmp
│ └── stuff...
├── package.json
├── tasks
│ ├── config
│ │ └── grunt task configs...
│ └── register
│ └── grunt task registrations...
├── tests
│ ├── unit
│ └── selenium
└── Gruntfile.js
Where should I place Gruntfile.js, app.js, package.json to achieve what I want? What other detail should I have to make grunt function and create artifacts as I want them?
Note: Obviously I'm not expecting to get all the details of grunt configuration. But I guess it helps to see where most important things go and how basic tasks could be configured.
Thanks for your answer.
It's hard to give a precise answer without a detail of your build steps, but I would suggest:
Gruntfile.js and package.json go to your root folder
you setup your individual build tasks (whatever they are) to output to build: see the doc of each task on how to do that, it's usually the dest option
Hope this helps a bit.