I'm trying to set up PHPCS to run with PSR2 by default instead of having to specify it on each run.
I set the default with phpcs --config-set standard PSR2 When I check the configuration, it appears to be set:
$ phpcs --config-show
Using config file: /usr/bin/CodeSniffer.conf
standard: PSR2
When I actually run it on files, it runs as PEAR:
$ phpcs -v transarray.php
Registering sniffs in the PEAR standard... DONE (28 sniffs registered)
Creating file list... DONE (1 files in queue)
Changing into directory /root
Processing transarray.php [PHP => 136 tokens in 26 lines]... DONE in 2ms (11 errors, 0 warnings)
...
If I run phpcs --standard=PSR2 ... it works correctly, but I would rather not have to include that every single time I run it.
The code errors reported match the standards in use.
According to the documentation you have to use default_standard as configuration key. So the command must be:
phpcs --config-set default_standard PSR2
Related
I am having a weird issue,
when I run
$ phpunit
I get
Fatal error: Call to undefined method PHPUnit_Framework_TestResult::warningCount() in /home/vagrant/.composer/vendor/phpunit/phpunit/src/TextUI/ResultPrinter.php on line 185
Call Stack:
0.0009 231392 1. {main}() /home/vagrant/.composer/vendor/phpunit/phpunit/phpunit:0
0.0065 743872 2. PHPUnit_TextUI_Command::main() /home/vagrant/.composer/vendor/phpunit/phpunit/phpunit:47
0.0066 744512 3. PHPUnit_TextUI_Command->run() /home/vagrant/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:106
1.1720 6818904 4. PHPUnit_TextUI_TestRunner->doRun() /home/vagrant/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:155
1.4597 16188088 5. PHPUnit_TextUI_ResultPrinter->printResult() /vagrant/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:446
However, when I run
$ ./vendor/bin/phpunit
it works as expected and runs my tests.
Maybe I have another program or something that is using the phpunit alias or something?
How can I debug to find that out?
Any ideas?
Assume you had installed phpunit from composer.json of current Laravel App.
Run this:
vendor/phpunit/phpunit/phpunit
Because the global one might be incompatible version of phpunit. Which is called and execute in the current package.
On windows I have an incompatible version installed globally.
To workaround, create "phpunit.bat" in root of project with contents:
"vendor/bin/phpunit"
This takes precendece over the phpunit in the system path.
How did you configure adding /vendor/bin to path?
I have this in my ~/.bashrc file:
PATH="$PATH:/path/to/vendor/bin"
This adds /vendor/bin/ to the end of your path, so if there is any other executable called phpunit earlier in your path - in your case, the globally installed one - it will be called instead.
To fix this, add vendor/bin to the beginning of your path in ~/.bashrc:
PATH="/path/to/vendor/bin:$PATH"
Then log out and log in or run source ~/.bashrc, and the system should then find /vendor/bin/phpunit first when you runphpunit.
On Windows, you can set an enviroment variable in your project's root directory.
Type this in your console/terminal:
set phpunit=vendor/bin/phpunit
I had the same problem with Laravel and PhpStorm, and after i typed this in my PhpStorm terminal, the problem was solved.
I've just found about about doskeys for Windows. I think they are called aliases on Mac, but they allow you to create a command as an alias for another command.
This way, I can use:
doskey macroName=macroDefinition
which in my case is:
doskey p=.\vendor\bin\phpunit
which then means I can just use the command p from my project folder for phpunit - much quicker!
For example I can now use the command:
p --filter my_single_test tests/MyExampleTest.php
I want to run RuboCop for VisualEditor repository. At the moment, the only Ruby file I could find in the repository is .docs/CustomTags.rb.
$ find . | grep rb
./.docs/CustomTags.rb
If I run only rubocop, it does not find any files:
$ rubocop
Inspecting 0 files
0 files inspected, no offenses detected
I guess it ignores files in folders that start with dot (.docs).
RuboCop documentation on including files says:
If you'd like it to check other files you'll need to manually pass
them in, or to add entries for them under AllCops/Include.
If I provide path to the file from the command line, RuboCop finds the file:
$ rubocop .docs/CustomTags.rb
Inspecting 1 file
W
(...)
1 file inspected, 26 offenses detected
Our continuous integration just runs rubocop for the repository, so I can not provide path to the file from the command line. I have to use AllCops/Include, but I can not figure out how to do it.
If I create a .rubocop.yml in the root of the repository:
AllCops:
Include:
- '.docs/CustomTags.rb'
and run Rubocop, it does not find the file:
$ rubocop
Inspecting 0 files
0 files inspected, no offenses detected
I have tried several variations of the .rubocop.yml file, including:
AllCops:
Include:
- '**/CustomTags.rb'
and
AllCops:
Include:
- '.docs/**/*'
But none of them are finding the file.
It was a bug in RuboCop. It is fixed now, but the gem with the fix is not released yet.
I'm getting this error on my mac osx build.
Primer3/eprimer3 issue:
Error: thermodynamic approach chosen, but path to thermodynamic parameters not specified
From:
http://www.mcardle.wisc.edu/mprime/help/primer3/primer3_manual.htm#globalTags
PRIMER_THERMODYNAMIC_PARAMETERS_PATH (string; default ./primer3_config)
This tag specifies the path to the directory that contains all the parameter files used by the thermodynamic approach. In Linux, there are two default locations that are tested if this tag is not defined: ./primer3_config/ and /opt/primer3_config/. For Windows, there is only one default location: .\primer3_config\.
I put the primer3_config in my PATH in bin and still cannot solve this issue. I even did:
export PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/Users/jared/Downloads/primer3-2.3.2/src
and
export PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/Users/jared/Downloads/primer3-2.3.2/src/primer3_config
to no avail.
According to the primer3 manual:
1.5. IMPORTANT: because PRIMER_THERMODYNAMIC_ALIGNMENT=1
PRIMER_THERMODYNAMIC_PARAMETERS_PATH must point to the right location.
This tag specifies the path to the directory that contains all the
parameter files used by the thermodynamic approach. In Linux, there
are two default locations that are tested if this tag is not
defined: ./primer3_config/ and /opt/primer3_config/. For Windows,
there is only one default location: .\primer3_config. If the the
parameter files are not in one these locations, be sure to set
PRIMER_THERMODYNAMIC_PARAMETERS_PATH.
So if you download and compile primer3 form source using the Make command, to get primer3 to run globally you need to copy the executueable, primer3_core, to your path and place the configuration directory, primer3_config in that same directory or at /opt/primer3_config
cd src
sudo cp primer3_core /usr/local/bin # or /usr/bin
sudo cp -r primer3_config /opt/
I has the same issue. I had installed Primer 3 using homebrew-science which was pretty painless. https://github.com/Homebrew/homebrew-science
I did try copying the primer3_config directory into the homebrew primer3 directory, ie:
/usr/local/Cellar/primer3/2.3.4/bin/primer3_config but this also did not work.
In the end I added the PRIMER_THERMODYNAMIC_PARAMETERS_PATH configuration to the primer 3 input file, and this worked. Note that the directory name must have a trailing slash. It is the last entry in the file below which is copied from the example file in the primer3 sources.
SEQUENCE_ID=example
SEQUENCE_TEMPLATE=GTAGTCAGTAGACNATGACNACTGACGATGCAGACNACACACACACACACAGCACACAGGTATTAGTGGGCCATTCGATCCCGACCCAAATCGATAGCTACGATGACG
SEQUENCE_TARGET=37,21
PRIMER_TASK=pick_detection_primers
PRIMER_PICK_LEFT_PRIMER=1
PRIMER_PICK_INTERNAL_OLIGO=1
PRIMER_PICK_RIGHT_PRIMER=1
PRIMER_OPT_SIZE=18
PRIMER_MIN_SIZE=15
PRIMER_MAX_SIZE=21
PRIMER_MAX_NS_ACCEPTED=1
PRIMER_PRODUCT_SIZE_RANGE=75-100
P3_FILE_FLAG=1
SEQUENCE_INTERNAL_EXCLUDED_REGION=37,21
PRIMER_EXPLAIN_FLAG=1
PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/usr/local/Cellar/primer3/2.3.4/bin/primer3_config/
=
Then run it like this:
$ primer3_core < example2
I've setup a custom configuration file for Pylint (name, conveniently, config). There has to be a way that I don't have to include --rcfile=config on every run. How can I set the config file permanently?
When you do not specify the --rcfile option, Pylint searches for a configuration file in the following order and uses the first one it finds:
pylintrc in the current working directory
If the current working directory is in a Python module, Pylint
searches up the hierarchy of Python modules until it finds a
pylintrc file. This allows you to specify coding standards on a
module-by-module basis. Of course, a directory is judged to be a
Python module if it contains an __init__.py file.
The file named by environment variable PYLINTRC
.pylintrc in your home directory, unless you have no home directory
or your home directory is /root
.pylintrc in the current working directory
/etc/pylintrc
Thus depending on the method you choose, Pylint can use a different configuration file based on the location of the code, the user or the machine.
Note that the configuration file only applies to Python files that are in modules. Thus, Pylint still uses its default rules when analyzing Python files in a directory with no __init__.py file.
For example, I have a bin/ directory containing command line applications. Ordinarily, this directory needs no __init__.py file because it is never imported. I had to add a bin/__init__.py file to get Pylint to analyze these Python files using my pylintrc file.
set the path to that file in the PYLINTRC environment variable, or rename the file $HOME/.pylintrc or /etc/pylintrc (the latter is probably only supported on *nix)
It can be done using .pre-commit-config.yaml. This snippet below need to be added to .pre-commit-config.yaml:
repos:
- repo: local
hooks:
- id: pylint
name: pylint
entry: pylint
language: system
types: [python]
args: [
"-rn", # Only display messages
"-sn", # Don't display the score
"--rcfile=.pylintrc", # Link to your config file
"--load-plugins=pylint.extensions.docparams", # Load an extension
]
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.