Minitest 5 update
by Josef Stribny
Hi Rubyists,
as you have probably noticed we would like to update Rails framework to the latest version (4.1) when it's released[1].
The biggest task for us in this change is the update of Minitest to version 5. This would require test suites
of many gems that depends on Minitest to be fixed.
Here are the most significant changes of Minitest 5 taken from the changelog[2]:
* 12 major (oft incompatible) changes:
* Renamed MiniTest to Minitest. Your pinkies will thank me. (aliased to MiniTest)
* Removed MiniTest::Unit entirely. No more manager objects.
* Added Minitest::Runnable. Everything minitest can run subclasses this.
* Renamed MiniTest::Unit::TestCase to Minitest::Test (subclassing Runnable).
* Added Minitest::Benchmark.
* Your benchmarks need to move to their own subclass.
* Benchmarks using the spec DSL have to have "Bench" somewhere in their describe.
* MiniTest::Unit.after_tests moved to Minitest.after_tests
* MiniTest::Unit.autorun is now Minitest.autorun. Just require minitest/autorun pls.
* Removed ParallelEach#grep since it isn't used anywhere.
* Renamed Runnable#__name__ to Runnable#name (but uses @NAME internally).
* Runnable#run needs to return self. Allows for swapping of results as needed.
That means the minimal changes needed to be done for every minitest test suite include:
* rename MiniTest::Unit::TestCase to Minitest::Test
* change require 'minitest/unit' (or 'test/unit') to require 'minitest/autorun'
* delete MiniTest::Unit.autorun (or use Minitest.autorun)
For some really simple test suites that might be enough. Look at the changes done in Rails 4.1[3]
or in my own little gem[4] for how the necessary changes may look like. For the others some additional
changes might be required.
Another problem are gems that depends on Gem::TestCase (like RubyGems plugins)
since Gem::TestCase is inherited from MiniTest::Unit::TestCase. I guess this can't be easily
solved at the moment, but we probably don't have many gems like that, or are we?
So what do you think of this change? Should we address it by updating upstream test suites?
Do you know about other issues that this can cause and I forgot to mention?
Josef
[1] https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.1
[2] https://github.com/seattlerb/minitest/blob/master/History.txt#L137
[3] https://github.com/rails/rails/commit/3073c531983de243219fb55be93fbcebfdd...
[4] https://github.com/strzibny/ruby-ares/commit/a1017ce59eeb8bfb5256b6e7789d...
9 years, 11 months
Ruby 2.1 mass rebuild - status update and possible merge
by Vít Ondruch
Hi Rubyists,
From 150 package which depends on ruby-devel [1], we already rebuild
approx 90 (there are some RoR packages in the mix). Other 31 packages
does not need build, since they are noarch or needed just for %check
section etc. So this gives us 30 more packages which remains for
rebuild. However, they are typically already FTBFS or the .spec file
contains some macros which needs maintainers attention.
The good news that except with minitest issues, the rebuild went rather
smooth IMO.
So, if nobody has objections, I'll ask rel-engs tomorrow to merge the
f21-ruby side tag back to the main f21 tag. This prevents possible
collisions with maintainers doing regular updates of their packages. We
can polish the remaining issues as time permits.
Thanks all for collaboration.
Vít
[1] repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | wc -l
9 years, 12 months
Enhancing isitfedoraruby
by Achilleas Pipinellis
Hey guys!
I meant to send this mail some time ago, but somehow stuck in my drafts
folder :\
I guess most of you know http://isitfedoraruby.com more or less.
I had a conversation with Mo and Vit about this app and how we
could add some new features to make it more appealing and handy to
packagers. Below are some of my thoughts of enhancement, any feedback is
appreciated.
- Write tests: Not exactly an app feature, but it should help in future
development.
- Gemfile tool [0]: Currently it does't have a handy output. I'd like to
see the versions in a table format and be able to extract more data,
like json files.
- Dependency checker: Currently we can see the dependencies of a gem [1]
in a format not very representational IMO. I had in mind making it look
like more or less with gemlou.pe [2].
- Package Status: Be it a gem or an app, it would be cool to have
something to show about their packaging progress. Debian gitlab
packagers, have set up a simple static page [3] showing the progress of
its packaging. It is really cool and it comes close to what I have in
mind :)
- UI/UX fixes: I have found some glitches that I would like to work on,
such as make optimizations on UI for small screens, etc.
- Many other stuff...
Also, I proposed this idea as a GSoC project [4]. If it gets chosen I'll
work on it full throttle :p
If not I'll be working on my free time :) Either way I think we could
make good use of these changes!
Cheers!
[0] http://www.isitfedoraruby.com/stats/gemfile_tool
[1] http://www.isitfedoraruby.com/fedorarpms/rubygem-Ascii85/full_deps
[2] https://www.gemlou.pe/loupes/devise/versions/2.2.3
[3] http://people.debian.org/~praveen/diasbar/
[4]
https://fedoraproject.org/wiki/GSOC_2014/Student_Application_Axilleas/Isi...
--
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me
10 years
