-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run the run.php script from within any directory #78
Comments
OK, good question. About the --src, I think you can use absolute paths, its not a problem. About the classloading, I'll have a look. I personnaly use small shell scripts in my projects to setup the working dir. I think we have a issue opened to provide a command in the /bin dir of composer, but I' havn't taken the time to solve this yet. |
Thanks for looking into this. I have been playing around a bit with the script.
Yeah, absolute paths are certainly working, I'm actually using that as some sort of "workaround" for now. But I would want to be able to use relative paths to the directory I'm calling from, not relative to the directory the run.php script is in. If you try to run
it is still throwing an error on the mentioned files not being found, as it would be able to load phpcheckstyle correctly, but cannot find for example the config file relative to the current working directory. But the current working directory needs to be to keep the relative source path working. I also tried something like
but still no luck. |
I think I understand your problem but I havn't been able to reproduce it yet. About the default config, it should be just a filename and it's relative to the projet path in the On my vagrant box, my default command looks like that : I've tried to go in the src directory and call it with relative paths : I've tried to go up 2 directories : But i'm using the composer autoloader. About the autoload i'm more worried, i know i've changed things several times, I struggle to find a solution that works both with and without composer. You can try to uncomment line 142 in run.php and comment line 143 to restore the previous way of working (path relative to the installation path of run.php). |
I have a project that uses PHPCheckstyle, but I'm using gradle to launch the process and I change the working dir to force it to be correct. I'll do some more tests ... |
Might be It's because I'm trying to do a |
When you do
it is running phpcheckstyle on the src directory inside the phpcheckstyle directory. However, the src I was referring to is the src directory in a symfony project. Sorry for the confusion. |
The project I have used to test is a Symfony project too. My directory looks like this : And in /project I have a script shell "phpcheckstyle.sh" with this content :
|
Ah, I see. I double checked my initial post, and I failed to mention something quite important: I'm installing phpcheckstyle as a global dependency. I'm using So my directory structure looks like this: Whenever I run a "phpcheckstyle.sh" with the following command (calling for the global phpcheckstyle):
I get the error:
When I run:
It returns this error (including the
If I run
it will run on the I should have mentioned the global requiring earlier, sorry for wasting your time... I hope with this new information, it is reproducable on your machine? |
I've done a fast test by moving my /vendor directory to the root of the system. And calling it using your first test worked : So it may have to do with the composer autoloader, maybe there is a difference in the autoload.php file itself when installed with the global option. I'll try to have a look as soon as I can find some time but I cannot do it right now. |
Nope, reinstalled composer using global, it still worked ... I've probably made something different than you because the composer directory ended up in the /home instead of at the root. But it worked anyway.
Can it be something else like a problem with a read permission on a file or something that makes the PHPCheckstyle class invisible ? |
Just to be sure: did you also remove phpcheckstyle from the local vendor directory after requiring it globally? I added a |
Yes, it was removed. |
Strange that it found the autoload file, don't know what might be the difference then. Should I be testing against the master branch or the latest release commit 21ceb84? |
Oh yes, i've been testing with the master branch. |
I just tried it against dev-master, the error changed to line 196, but it still cannot find the class PHPCheckstyle:
I'll look into providing a simple example later (after hours), if that's okay? |
okay ^^ |
Simple example, will install git, composer, phpcheckstyle, and run it against the ./src directory.
Throws as error:
Edit: this runs on Mac OS bash with "docker for mac" |
Can you reproduce it with this example? |
Sorry, I have been quite busy lately, I havn't touched this project for a while. All the tests I've done where on a Vagrant Box with Debian, and I havn't been able to reproduce the problem so far. I'll do some more tests when I can find so time. |
I've done the install using the same command : |
First of all: big thanks for this awesome tool!
Trying it out however, I have run into a small problem with using relative paths. Running the following line:
I receive the error
Trying to load the
/composer/vendor/autoload.php
solves this, but it will still complain about not finding the default config file, as it is defined relatively to the location the script is run from, not relatively to the script itself.This dependency on the location where php is run from is found on other lines as well:
Is there some way to update run.php to make the script run from anywhere? Or even make it possible to run it as a binary in /composer/vendor/bin (which might take advantage from these same changes)? Honestly, I'm not really sure if these would be the only changes needed to being able to run the above line, as
--src "./src"
is still using a relative path to the location the script has been called from...Thanks for looking into this. I would be glad to help to provide further details if needed.
The text was updated successfully, but these errors were encountered: