BACKGROUND
I am working on a PHP project with unit testing and Travis CI. (It is Source Speak.)
This project "depends" on Twitter Bootstrap. In other words it includes the line:
//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css
I can find out the latest release of bootstrap by querying:
https://api.github.com/repos/twbs/bootstrap/releases
QUESTION
How do I add a unit test that confirms that all URLs in the project like //netdna.bootstrapcdn.com/bootstrap/*/css/bootstrap.min.css are using the latest version of Bootstrap?
-and-
Is there any documented best practice that says I shouldn't be doing this?
Edit: Yes, bower is a good solution as well and is probably preferable if you are already using bower for something else.
I would write a shell script that curl's the version from the url and then downloads it from the version specified in the original curl call. There is no documented best practice that says you shouldn't be doing this, but I would probably add the bootstrap css file to version control so that you can track when you updated bootstrap and easily downgrade if a new version breaks anything.
If you need any help with the shell script let me know with a comment and I can show you one.
Related
I have been making a CMS as a project for a little while now, and am currently working on the plugin management section. Instead of building my own repository & update manager, I've been toying with the idea to use composer instead. The issue is I want the admins on the site to be able to add/remove plugins at will.
So I was thinking, how bad of an idea would it be to build a front-end which runs composer? Composer is just PHP after all, it's meant to be run on production environments (granted with a composer.lock file though), and it'd resolve all of my repository, update, and dependency needs.
I knocked out a quick test script, I built and passed in a custom configuration file (instead of composer.json, the installed plugins list is stored in the database), and everything seems to be working fine. But I can't shake the feeling of this being a bad idea.
Does anyone have experience with this, and whether or not it is a good or bad idea?
Using Composer as an embedded dependency manager with a front end is actually a very valid use case for it. Here are some links with information, as well as a project meant specifically to help with embedding composer into an application.
https://github.com/dflydev/dflydev-embedded-composer
https://sculpin.io/documentation/embedded-composer
http://srcmvn.com/blog/2013/05/23/symfony-live-2013-portland-embedded-composer
We're starting a new project, and we're managing dependencies with Composer. We'll probably build our app on top of Laravel 4. But we'll also create our own library, which we will use for all our next projects, not just this one.
So, we have this terrible doubt: what's the best way to develop a library using composer?
If we list that new library as a dependency, every time we modify it we will have to commit the change to the repository and then call composer update.
That seems terrible!
Is there a better way to do that?
I think there are two ways to handle this, which I use depending on the case:
The library is a pure library, which is standalone, fully tested, and develop it using TDD to ensure that it all works. That way it can be used with the "commit, update" cycle you described just fine I think.
You are developing a plugin or something that must be integrated in something else (application/framework) and testing it standalone is more difficult, or you are developing it very tightly with your application. In this case require the dev-master version of the library so Composer installs it with a git clone (if it was already installed as a tag you will have to rm -rf vendor/your/library to force a reinstall as opposed to an update). You can also force this for tagged releases using the --prefer-source flag. Then once you have a clone in the vendor dir you can very easily work directly in there. If you do work in a team though you will still need to do this commit and then update to make sure the others get the latest version.
The third alternative is to just develop the code in the src/ directory of your application until it is mostly stabilized and then you can extract it as a new package and add it back as a dependency, then fall back on the first two ways I described because it will then be a lot more viable.
If you set the dependency to the repository master branch instead of a packaged distribution file, Composer will check out a working copy into the vendors folder. You can modify this working copy right in the vendors folder, as if it's part of the main project, but then commit it into its own repository. You'll indeed have to make sure to composer update after that to keep the composer.lock file in sync with the development of that library though.
It's still the more convenient way to develop a project in tandem with a dependency.
If you aim to develop a truly awesome library, then you should try to develop it independently of any other software you create.
It should fulfill one exact task only. And this probably is done after some commits, so the initial creation of the library should take only a week or two to come to a stable first version. And this version can be tagged and then used elsewhere.
When tagging, strictly try to follow semantic versioning - that way you can use the library with a version restriction like "~1.0", meaning at least version 1.0, but anything up to 1.9999 is acceptable, as long as it is not 2.0 (which would mean incompatible changes).
And then you really do not need to update any other software when you release a new version of the library. You only need to update if you want to include fixed bugs. Without bugfixes, you can update, but there is no need to do so immediately after the library's new version release.
Composer will take care of all the dependencies you need. The most important thing if you start a new library is to include the composer.json right from the start into the repository.
What if you really want to always include the newest release of the library in every other software you write? I'm not sure you realize the implications this has. It means that you are strictly binding your other software to the most recent library version. Break that version, or introduce a nasty bug, and all your software breaks. So being able to update or not actually is a feature. You will find that all foreign libraries you might use will follow the same release mechanism: They tag a new version if an important bug was fixed, or if a reasonable amount of new features was implemented. They do not wait for you to approve a new version - you have to approve THEIR new version in your software by explicitly updating to the most recent one. And the same should apply to an internal library.
Try to avoid fiddling with "dev-master" solutions mentioned here. They might work, but Composer works best if used with tagged versions. If you have a reasonably stable state of your library, tag it with "0.0.0" and include that version everywhere else instead of "dev-master". And then tag according to semantic version rules.
I would like to package PHPUnit and various other test dependencies into a phar and put that into svn. This way I can run phpunit on any client machine without needing pear. Can this be done?
Current status:
Work on a phpunit.phar has started in the phpunit repo but the generated phar is not stable and not feature complete.
If it gets there there will be official releases
Original answer:
If you can I'll give you 500 rep, a 100 Bucks and my first born.. well no.. just the first two.
To be serious:
I've nagged the creator of PHPUnit about this topic on at least 3 conferences now and well.. it doesn't seem like it's possible.
There are a couple of issues with that. First off PHPUnit spawns new php processes for test isolation. The problem with this is that a phar can't tell which php executable called it. So if you start phpunit with a custom compiled version it would use the "default" php installed to spawn the isolated tests.
Secondly as far as i know and have been told it's not possible to put static files like images and css in a phar. Which makes generating code coverage a lot harder. That would require some work on that part.
There are other issues i can't recall exactly recall right having to do with xDebug being able to provide code coverage for phars (and phpunit relying on not generating overage for it's own code and so) and others things.
There once was a phar but from my understanding that just doesn't work out with the current state of phpunit and never really worked completly.
I'm not saying it can't be done just that various people already have given up on creating a phpunit.phar including the guy how develops it. (That is just my impression, i of course can't speak for Sebastian here and might be completely wrong, take this as a little disclaimer)
Putting PHPUnit into SVN
You don't have to build a .phar to do so!
For my company I maintain a svnd version of PHPUnit. It's not the recommended way of using it but it works without much issues!
Follow the "using from a git checkout" instructions on the phpunit github site. You then need to put those files into your php include path and it works.
My suggestion would be to create a custom phpunit.sh that modifies the include path and then calls the original phpunit.sh passing along all arguments. It's a little bit of work but it works quite well and it is a hell of a lot easier than creating a phar archive :)
From the new PHPUnit page:
We distribute a PHP Archive (PHAR) that contains everything you need in order to use PHPUnit. Simply download it from here, make it executable, and put it into your $PATH, for instance......
I've installed Eclipse 3.5.1 (PDE), which I believe I got from Zend's download site (it was a while ago on my travel laptop). I can't get auto-complete to work for any of my included libraries. I've tried both adding the libraries to the 'include path' and just linking the files to a subdirectory of the project. Neither gets me auto-complete of the library classes.
My normal development system has an older version of Eclipse which I don't update, because it currently works well, and I fear an update will change that. I find configuring eclipse more work that actual coding, and more voodoo that mod_rewrite. I doubt I'm alone.
Any secret to getting auto-complete working?
No you're definitely not alone! I have experienced this problem in many installations of Eclipse (after updates and such etc etc). Try running Build Project. I know that solution has worked in some instances for me. My last installation I was running Eclipse Galileo and once I finally got the intellisense to at least work it was extremely slow. I tried lowering the time delay for the intellisense which helped in php files (still had a 1.5 second delay at least) but made it way over-sensative in my view scripts for example.
I finally bit the bullet and switched to Zend Studio 8. (At least they've knocked the price down $100 haha).
Eclipse has a quirky auto-complete but the Zend one is excellent! :)
You can add a PHP library to the project in Project properties/PHP Include Path/Libraries. After that, autocomplete will index all php files in that directory.
Maybe it's not the best solution for you, because it doesn't care about whether the file is included or not in the given script. If I include /usr/share/pear, and now I see all PEAR libs' functions everywhere.
I'm having issues with Zend_Gdata_YouTube.
It seems unable to locate the file VideoQuery.php despite the fact it is one of the directories mentioned in the warning messages.
Also I created a standalone version of the example just including 'Zend/Gdata/YouTube.php'. This works fine.
I've dropped the error messages then the class followed by the working example into a paste bin.
Paste Bin
I got the same error after I upgraded from ZF 1.8.0 to 1.8.4, after searching for a solution with no luck I posted my error on the ZF Gdata mail list and Trevor Johns was nice enough to get back to me with this response:
"This looks like this issue:
http://framework.zend.com/issues/browse/ZF-7013
This will be fixed in the next release of Zend Framework. If you don't
want to wait that long, you can either:
Download a development snapshot from here:
hxxp://framework.zend.com/code/browse/~tarball=zip/Zend_Framework/standard/trunk/trunk.zip
Use version 1.8.3:
hxxp://framework.zend.com/releases/ZendFramework-1.8.3/ZendFramework-1.8.3.tar.gz
Don't use Zend_Loader's autoloader functionality. (This bug only
seems to show up if you're trying to autoload the classes.)"
I'll be rolling back my ZF version until the next release.
p.s. had to substitute http with hxxp because "new users can only post a maximum of one hyperlink" apparently.
The files Zend\Gdata\Media\Extension\VideoQuery.php and Zend\Gdata\YouTube\Extension\VideoQuery.php do not exist in the framework. I think the file you want is Zend\Gdata\YouTube\VideoQuery.php
Does this help? What code is using these classes, your code or the framework code?