Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support lowercased phakefile filenames. #29
Support lowercased runfile names to be recognized as well. Example:
Tests for proper file recognition added aside.
PHPUnits bootstrap now uses composers autoloader in order to benefit
Please note: Usage of 5.4 short array syntax in tests! Consequence:
Feel free to review and comment. Thank you.
Thanks for this PR!
Would you care to elaborate on the rationale to support lowercase filenames and why sticking to the uppercase one is not an option in your case?
The provided unit tests are very much appreciated. The new developer dependencies certainly introduce some additional complexity, but I'd love to hear some more opinions on that matter (ping @jaz303). Also, I think we shouldn't drop support for PHP 5.3 unless there's a compelling reason to.
Otherwise, the changes look good to me, thanks again!
Re: the feature itself, happy to include this. The capitalisation is a throwback to Rake/Make and not really followed anywhere else.
Tests are a good thing and this PR seems to lay a good foundation for increased test coverage in the future. I haven't done any serious PHP development in ~2 years so I'm a bit out of touch with how projects are organised but if the approach outlined here reflects current best practices I don't see any reason not to merge.
It should be possible to run the tests wherever deployed, so in my mind to say the tests are incompatible with 5.3 is to say the whole project is incompatible with 5.3. That said, 5.3 was EOL'd around 9 months ago so I'm not precious about keeping compatibility - if dropping it stands to improve other aspects of the project.
Thanks for considering this PR.
@clue, the reason for lowercase filename support is simply the expectation that the lowercase named version is being recognized as well. This in fact is a reference to the sibling (or motivating) projects Rake/Make. Both rake and make support lowercase rakefile / makefile. I was just expecting phake to behave as rake does on that.
Regarding 5.3 compatibility, I pretty much second the view of @jaz303. If 5.3 is going to be supported, then the tests should adhere to that. On the flip side, 5.3 really rarely can be found on serious hosters anymore. Nowadays, 5.4 is like the minimum to host any PHP project. An argument for 5.4 is terse syntax and the builtin webserver in CLI. This especially makes unit testing a lot easier.
After all, it's your decision to either drop 5.3 or move to 5.4 support. If you were to stick on 5.3, I can happily replace the 5.4-specific stuff with more traditional statements.
Looking forward for your feedback. Hope it helps!
Totally makes sense to me. So yeah, I'm all for adding this feature
Perhaps we should consider in which order we look for those files, now that we have a total 4 different file name conventions.
I beg to differ. Personally, I'm using PHP 5.5 and am enjoying its new features (the embedded webserver being one of them).
However, PHP 5.4+ has yet to see major adoption and I'm a bit uneasy with forcing users to upgrade just because using the short array syntax (
Please don't get me wrong, I'm not saying we should never move. It absolutely makes sense to upgrade once we either require newer features (which frankly I currently don't see being the case) or our minimum requirement starting to become a burden.
Ultimately, I'm not the one to decide, I'm just raising my concerns :) Perhaps it's easier to separate this discussion to another ticket so we can just merge the new feature?
@clue, as for the order of the filenames to be recognized, the implementation just reflects the order you wrote down. Hope this fits for you.
Thanks for your consideration @ilkerde!
The feature looks good to me, I've finally had the time to test it locally and it works as expected
One thing that bothers me though is that while previously running
Do you happen to have any insight on whether there's any consensus on installing phpunit (etc.) via dependencies? I've scanned quite a few projects and they tend towards relying on a system-wide installation of phpunit instead. But I'm very open for any reasons either way.
Hi @clue, thanks for your testing and feedback, hope we can use the feature soon in phake.
I wholeheartedly understand your concerns regarding
I'm dealing with hundreds of repositories, of which dozens use PHP. All those repos have their own dependencies, mostly locking down specific versions of their own dependencies. That's why I install stuff locally - except the package manager itself. It helps me alot having a sane environment for all those projects. (By the way, I install phake to
Interestingly, I never had the annoyances you are reporting with having to reinstall packages when switching branches - although I'm a fair heavy user. Maybe it's because I always .gitignore the
Sure, from time to time there is some sort of annoyance between branches, especially when specific branches update dependencies while others aren't refreshed - but this is even more a big issue when they are installed globally, ultimately rendering entire projects to be unusable.
In python land, we have things like virtualenv helping us to mitigate these issues. However, I always felt ok with the local package install option of composer.
In order to not always be obliged to type in
Now that's about my view and experiences regarding local tool installs. That being said, please let me emphasize clearly that I really don't care whether your preference is to have phpunit package installed locally or globally. I honestly feel fine with both. Consequently, if you should come to the conclusion to rather prefer phpunit installed globally, then please do. It's basically nothing more than removing a single line.
I just wanted to contribute in making phake behave like rake or make. Just because I was used to this behavior. I hope this is ok for you. Thanks for your efforts!
Thanks for taking the time to write such an thorough explanation @ilkerde.
After some further consideration and some additional tests, I wholeheartedly understand and support your wish to include the development tools.
I've just had the time to check this behavior with several other libraries and it turns out my concerns were mostly untenable. I was under the assumption that running a system wide bin would not work with in conjunction with other local dependencies (such as the vfsStream) on it. As it turn out, they work just fine with a local as well as a global installation, so you can run both just
I fully support your reasoning, so sorry for the confusion! Would you care to resolve the remaining merge conflicts? Given @jaz303 already stated his support, I'm looking forward to merge this then, thanks!