I’ve added a wiki page with installation instructions here:
Please let me know if anything is missing or unclear.
Sylvester
signature.asc (203 Bytes)
There’s one little detail you’re missing on the instructions. By
default, git won’t pull in remote branches (like “development”). So
you need to add the command to do that (which I forget).
I don’t know, is it just that the ‘-t’ here should be a ‘-b’?
$ git checkout -t origin/development
Making progress, but stuck on nokogiri; any ideas? Wondering if it’s
some problem with OS X and brew?
Installing nokogiri (1.5.5) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native
extension.
/usr/local/Cellar/ruby/1.9.2-p180/bin/ruby extconf.rb
checking for libxml/parser.h… *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.
Yes, libxml often causes installation problems. I’ve removed all hard dependencies to it for that reason, save for schema validation.
There are some instructions on the Nokogiri site at:
http://nokogiri.org/tutorials/installing_nokogiri.html
There are more instructions for homebrew 0.9 and 0.8 – are you using any of these versions?
signature.asc (203 Bytes)
Sigh … yeah, OS X is a mess. Anyway, I got the dependencies
installed finally (with help from the nokogiri site), but now run into
this problem. I think I’m done for the day.
$ rake
/Users/darcusb/.rvm/rubies/ruby-1.8.7-p358/bin/ruby -S rspec
./spec/dependent_styles_spec.rb ./spec/independent_styles_spec.rb
./spec/repository_spec.rb --require spec_helper.rb --format progress
–color
/Users/darcusb/code/styles/spec/spec_helper.rb:21: undefined method
with_index' for #<Array:0x1016a0a70> (NoMethodError) from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration.rb:434:inrequire’
from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration.rb:434:in
requires=' from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration.rb:434:inmap’
from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration.rb:434:in
requires=' from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration_options.rb:20:insend’
from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration_options.rb:20:in
configure' from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration_options.rb:19:ineach’
from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/configuration_options.rb:19:in
configure' from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/command_line.rb:21:inrun’
from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/runner.rb:69:in
run' from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/gems/rspec-core-2.11.0/lib/rspec/core/runner.rb:8:inautorun’
from /Users/darcusb/.rvm/gems/ruby-1.8.7-p358/bin/rspec:19
Loading dependent stylesrake aborted!
/Users/darcusb/.rvm/rubies/ruby-1.8.7-p358/bin/ruby -S rspec
./spec/dependent_styles_spec.rb ./spec/independent_styles_spec.rb
./spec/repository_spec.rb --require spec_helper.rb --format progress
–color failed
Tasks: TOP => default => spec
(See full trace by running task with --trace)
Did you run bundle install before that?
Alternatively, you could also run bundle exec rake to make sure the correct versions of the dependencies are being used?
signature.asc (203 Bytes)
This is because it’s running under Ruby 1.8 and the ‘with_index’ method is 1.9 only. I have myself installed Ruby 1.9 using rbenv and ruby-build. It’s really a very nice way to have several versions of Ruby installed, wth very minimal additions to your bash profile, and without interfering at all with your system. It all goes in your home folder in ~/.rbenv.
You install first rbenv, and use ruby-build to add Ruby 1.9.3. The instructions are very clear:
After that is done, I recommend starting with a fresh new Terminal window to make sure the .profile is loaded and the paths set properly. Then switch to Ruby 1.9.3:
rbenv global 1.9.3-p194 (or whatever you installed; in theory it should also work with just rbenv local 1.9.3-p194 once you are inside the CSL style directory)
You can check the paths/versions are good:
which gem
which ruby
You will then have to install the gems again for that version, as instructed by Sylvester. Note also when you are in the csl directory with the Gemfile, the command:
bundle show bundler
should show soemthing like
/Users/charles/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/bundler-1.1.5
Anyway, rbenv works great (it was recommended to me by our Mekentosj Ruby gurus).
charles
Yes, that was it.
I was avoiding 1.9 because of previous issues I recall with nokogiri.
But it works now.
Cool.
Only thing a little odd is the opaque progress indicator.
Bruce
Thanks for spotting the error Charles; I will change that line in the test script to make it work on 1.8. too.
Bruce, can you explain what is odd about the progress indicator?–
On 19.07.12 03:49 Bruce D’Arcus wrote:
On Wed, Jul 18, 2012 at 8:36 PM, Charles Parnot <@Charles_Parnot> wrote:
This is because it’s running under Ruby 1.8 and the ‘with_index’ method is
1.9 only.
Yes, that was it.
I was avoiding 1.9 because of previous issues I recall with nokogiri.
But it works now.
Cool.
Only thing a little odd is the opaque progress indicator.
Bruce
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
Right, I just changed the test script a little bit to make it 1.8 compliant. I also just ran the tests successfully on a Mac with the version of Ruby (1.8.) that ships with OS X by default so I hope that this reduces installation difficulties.
Travis was recently making builds for commits to the master branch. I think that was because it had not seed a commit to the development branch since Rintze activated the service hook and I suspect it had not picked up our configuration file yet. That’s likely the reason why some of you may have received unwanted notifications (all repository admins). If you look at the build history [1] you’ll see that travis finally ran the tests after my last commit. I hope that from now on only commits to development will trigger the build on travis. Otherwise we might have to add the .travis.yml configuration file to the master branch as well to ensure that commits there are ignored by the build-system.
http://travis-ci.org/#!/citation-style-language/styles/builds
Once we confirm this works we should start committing to the development branch instead of the master branch.
Sylvester
signature.asc (203 Bytes)
It looks like it’s still running Travis on the ‘master’ branch:
http://travis-ci.org/#!/citation-style-language/styles/builds/1904439
To some extent, one could argue it’s still useful to have the script run on that branch, since the content on that branch needs to be validated even more. Is the downside that we have to add the test elements to that branch as well? As we start merging commits from ‘development’ into ‘master’, those will be picked up as well.
charles
It looks like it’s still running Travis on the ‘master’ branch:
To some extent, one could argue it’s still useful to have the script run on that branch, since the content on that branch needs to be validated even more. Is the downside that we have to add the test elements to that branch as well? As we start merging commits from ‘development’ into ‘master’, those will be picked up as well.
I don’t think there’s a real downside to running the tests on master, as well, unless we are concerned about the additional clutter caused by the test files. If not the tests, it seems we will have to at least add the .travis.yml file to make sure that travis sees our configuration. (I’m travelling at the moment so I can’t look at this until later this weekend.) And you’re right that not adding the tests will become a nuisance if we want to merge development with master down the road.
Sylvester
signature.asc (203 Bytes)
I don’t think there’s a real downside to running the tests on master, as well, unless we are concerned about the additional clutter caused by the test files. If not the tests, it seems we will have to at least add the .travis.yml file to make sure that travis sees our configuration. (I’m travelling at the moment so I can’t look at this until later this weekend.) And you’re right that not adding the tests will become a nuisance if we want to merge development with master down the road.
OK! Now, is there any simple way to “hide” the tests inside a subfolder in the repository? If easy, then maybe it’s worth the extra effort to keep the file layout “clean”?
Thanks again so much for this work, this is exactly what we have been needed for a while!
charles
Well, before we settle this, what’s the workflow we’re imagining for adding
style changes?
I don’t think there’s a real downside to running the tests on master, as well, unless we are concerned about the additional clutter caused by the test files. If not the tests, it seems we will have to at least add the .travis.yml file to make sure that travis sees our configuration. (I’m travelling at the moment so I can’t look at this until later this weekend.) And you’re right that not adding the tests will become a nuisance if we want to merge development with master down the road.
OK! Now, is there any simple way to “hide” the tests inside a subfolder in the repository? If easy, then maybe it’s worth the extra effort to keep the file layout “clean”?
The test files itself are all ‘hidden’ in the spec folder anyway. The ‘clutter’ in the root directory is the Rakefile and the Gemfile (a Gemfile.lock is added when you run bundler) – I kept these in the main folder for two reasons: a) it’s easier the default file arrangement and therefore (I presumed) easier to install/setup b) travis-ci assumes to find the files there too. As regards a) I’m actually not sure it’s true: I mean we could move everything into the spec folder and run the tests from there, that shouldn’t be a problem. Regarding the travis-ci it should not be too difficult to setup either, because you can pretty much specify what scripts to run etc.
I like the current file arrangement, but it’s merely a preference and it should be possible to make a switch.
Another question we should keep in mind whether it may not be easier to work on the master branch and have separate release branches? Especially if we may want to keep separate versions of styles in the future (i.e., 1.0 branch, 1.0.1 branch).
Thanks again so much for this work, this is exactly what we have been needed for a while!
CiteProc-Ruby was accepted by the Google Summer of Code program this year – so thanks to the support by Google and the Berkman Center at Harvard I’ve been able to spend more time working on rewriting the cite processor and a separate CSL library which makes writing tests very easy 
Sylvester
signature.asc (203 Bytes)
My understanding is this:
Styles changes are pushed by controbutors to the ‘development’ branch. This triggers a Travis CI run. If the tests succeed, the corresponding commit is fast-forwarded on the ‘master’ branch.
That makes sense to me. But then if that’s the case, we don’t need to
test on master; do we (unless we’re not confident people will only
work on “development”)?
The test files itself are all ‘hidden’ in the spec folder anyway. The ‘clutter’ in the root directory is the Rakefile and the Gemfile (a Gemfile.lock is added when you run bundler) – I kept these in the main folder for two reasons: a) it’s easier the default file arrangement and therefore (I presumed) easier to install/setup b) travis-ci assumes to find the files there too. As regards a) I’m actually not sure it’s true: I mean we could move everything into the spec folder and run the tests from there, that shouldn’t be a problem. Regarding the travis-ci it should not be too difficult to setup either, because you can pretty much specify what scripts to run etc.
I like the current file arrangement, but it’s merely a preference and it should be possible to make a switch.
The Gemfile etc… were what I had in mind, but don’t worry. That’s really just cosmetic. It works this way, and it’s fine
Another question we should keep in mind whether it may not be easier to work on the master branch and have separate release branches? Especially if we may want to keep separate versions of styles in the future (i.e., 1.0 branch, 1.0.1 branch).
I agree, but that can always be changed in the future.
Thanks again so much for this work, this is exactly what we have been needed for a while!
CiteProc-Ruby was accepted by the Google Summer of Code program this year – so thanks to the support by Google and the Berkman Center at Harvard I’ve been able to spend more time working on rewriting the cite processor and a separate CSL library which makes writing tests very easy
Congrats!
charles
Yes, that was more coming from the “it does not hurt” perspective 