Hello,
Currently I am dealing with several rubygems (arel, regin) that do not contain bundled their test suites, although the test suite is usually available on GitHub. It would be nice to run the test suite during packaging, however I am reluctant to modify the package in that way that it will include the test suite.
So here is my proposal:
# Preparation of the test suite # git clone http://github.com/somerepo/somegem.git # cd somegem/ # tar czvf somegem-tests.tgz spec/ Source1: some-tests.tgz
%check mkdir %{_tmppath}/%{gemname}-%{version} tar xzvf %{SOURCE1} -C %{_tmppath}/%{gemname}-%{version} pushd %{_tmppath}/%{gemname}-%{version} ruby -I%{buildroot}%{geminstdir}/lib `which spec` spec popd rm -rf %{_tmppath}/%{gemname}-%{version}
What is your opinion?
Vit
Couple of comments.
On 01/19/2011 10:45 AM, Vít Ondruch wrote:
Hello,
Currently I am dealing with several rubygems (arel, regin) that do not contain bundled their test suites, although the test suite is usually available on GitHub. It would be nice to run the test suite during packaging, however I am reluctant to modify the package in that way that it will include the test suite.
So here is my proposal:
# Preparation of the test suite # git clone http://github.com/somerepo/somegem.git # cd somegem/ # tar czvf somegem-tests.tgz spec/ Source1: some-tests.tgz
This looks good save the fact that you will always get the tests in the lastest upstream HEAD with these commands. Often times projects hosted on github or managed via git in general will tag their releases so you can checkout the specific version of the test suite which you need. If the release isn't tagged you will have to find the commit which corresponds to the released gem anyways.
To checkout a specific tag or commit, simple run the following command between your "cd somegem/" and "tar czvf..." commands above
git checkout <tag-or-commit-id>
%check mkdir %{_tmppath}/%{gemname}-%{version} tar xzvf %{SOURCE1} -C %{_tmppath}/%{gemname}-%{version} pushd %{_tmppath}/%{gemname}-%{version} ruby -I%{buildroot}%{geminstdir}/lib `which spec` spec popd rm -rf %{_tmppath}/%{gemname}-%{version}
What is your opinion?
Vit
Its not a bad idea to extract the test source in the %prep or %install sections and leave it around, marking it as %doc in the %files section (or putting it in the docs subpackage). If you're running gem install in the %prep section, add the following to that section
tar xzvf %{SOURCE1} -C .%{geminstdir}
This is how we're doing it in the activesupport rpm (and all other rails rpms starting w/ 3.0.3)
http://mo.morsi.org/files/rpms/rubygem-activesupport.spec
As always, additional thoughts and improvements are welcome.
-Mo
Dne 19.1.2011 17:00, Mohammed Morsi napsal(a):
Couple of comments.
On 01/19/2011 10:45 AM, Vít Ondruch wrote:
Hello,
Currently I am dealing with several rubygems (arel, regin) that do not contain bundled their test suites, although the test suite is usually available on GitHub. It would be nice to run the test suite during packaging, however I am reluctant to modify the package in that way that it will include the test suite.
So here is my proposal:
# Preparation of the test suite # git clone http://github.com/somerepo/somegem.git # cd somegem/ # tar czvf somegem-tests.tgz spec/ Source1: some-tests.tgz
This looks good save the fact that you will always get the tests in the lastest upstream HEAD with these commands. Often times projects hosted on github or managed via git in general will tag their releases so you can checkout the specific version of the test suite which you need. If the release isn't tagged you will have to find the commit which corresponds to the released gem anyways.
To checkout a specific tag or commit, simple run the following command between your "cd somegem/" and "tar czvf..." commands above
git checkout<tag-or-commit-id>
Yes, you are right. The "git clone" comment was not accurate enough.
%check mkdir %{_tmppath}/%{gemname}-%{version} tar xzvf %{SOURCE1} -C %{_tmppath}/%{gemname}-%{version} pushd %{_tmppath}/%{gemname}-%{version} ruby -I%{buildroot}%{geminstdir}/lib `which spec` spec popd rm -rf %{_tmppath}/%{gemname}-%{version}
What is your opinion?
Vit
Its not a bad idea to extract the test source in the %prep or %install sections and leave it around, marking it as %doc in the %files section (or putting it in the docs subpackage). If you're running gem install in the %prep section, add the following to that section
tar xzvf %{SOURCE1} -C .%{geminstdir}
This is how we're doing it in the activesupport rpm (and all other rails rpms starting w/ 3.0.3)
http://mo.morsi.org/files/rpms/rubygem-activesupport.spec
As always, additional thoughts and improvements are welcome.
I know, I saw the activesupport. However I believe:
1) The package should be as close to upstream as possible, therefore I am reluctant to keep the test in the rpm. 2) User of the library doesn't care about tests, because he relays on the author of the library and on packager. Although test can be viewed as a documentation, I believe that most of the users will prefer other ways how to reach it (rdoc.info, github). So again, the test are just occupying space on your hard drive.
But since this is philosophical topic, I would love to hear some opinion from others.
Vit
-Mo
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 19.1.2011 17:40, Vít Ondruch napsal(a):
Dne 19.1.2011 17:00, Mohammed Morsi napsal(a):
Couple of comments.
On 01/19/2011 10:45 AM, Vít Ondruch wrote:
Hello,
Currently I am dealing with several rubygems (arel, regin) that do not contain bundled their test suites, although the test suite is usually available on GitHub. It would be nice to run the test suite during packaging, however I am reluctant to modify the package in that way that it will include the test suite.
So here is my proposal:
# Preparation of the test suite # git clone http://github.com/somerepo/somegem.git # cd somegem/ # tar czvf somegem-tests.tgz spec/ Source1: some-tests.tgz
This looks good save the fact that you will always get the tests in the lastest upstream HEAD with these commands. Often times projects hosted on github or managed via git in general will tag their releases so you can checkout the specific version of the test suite which you need. If the release isn't tagged you will have to find the commit which corresponds to the released gem anyways.
To checkout a specific tag or commit, simple run the following command between your "cd somegem/" and "tar czvf..." commands above
git checkout<tag-or-commit-id>
Yes, you are right. The "git clone" comment was not accurate enough.
%check mkdir %{_tmppath}/%{gemname}-%{version} tar xzvf %{SOURCE1} -C %{_tmppath}/%{gemname}-%{version} pushd %{_tmppath}/%{gemname}-%{version} ruby -I%{buildroot}%{geminstdir}/lib `which spec` spec popd rm -rf %{_tmppath}/%{gemname}-%{version}
What is your opinion?
Vit
Its not a bad idea to extract the test source in the %prep or %install sections and leave it around, marking it as %doc in the %files section (or putting it in the docs subpackage). If you're running gem install in the %prep section, add the following to that section
tar xzvf %{SOURCE1} -C .%{geminstdir}
This is how we're doing it in the activesupport rpm (and all other rails rpms starting w/ 3.0.3)
http://mo.morsi.org/files/rpms/rubygem-activesupport.spec
As always, additional thoughts and improvements are welcome.
I know, I saw the activesupport. However I believe:
- The package should be as close to upstream as possible, therefore I
am reluctant to keep the test in the rpm. 2) User of the library doesn't care about tests, because he relays on the author of the library and on packager. Although test can be viewed as a documentation, I believe that most of the users will prefer other ways how to reach it (rdoc.info, github). So again, the test are just occupying space on your hard drive.
But since this is philosophical topic, I would love to hear some opinion from others.
One more downside is that RSpec are usually defined just as a build time dependency, therefore it is not ensured that user can run the specs anyway.
Vit
-Mo
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 01/19/2011 11:54 AM, Vít Ondruch wrote:
Dne 19.1.2011 17:40, Vít Ondruch napsal(a):
Dne 19.1.2011 17:00, Mohammed Morsi napsal(a):
Couple of comments.
On 01/19/2011 10:45 AM, Vít Ondruch wrote:
%check mkdir %{_tmppath}/%{gemname}-%{version} tar xzvf %{SOURCE1} -C %{_tmppath}/%{gemname}-%{version} pushd %{_tmppath}/%{gemname}-%{version} ruby -I%{buildroot}%{geminstdir}/lib `which spec` spec popd rm -rf %{_tmppath}/%{gemname}-%{version}
What is your opinion?
Vit
Its not a bad idea to extract the test source in the %prep or %install sections and leave it around, marking it as %doc in the %files section (or putting it in the docs subpackage). If you're running gem install in the %prep section, add the following to that section
tar xzvf %{SOURCE1} -C .%{geminstdir}
This is how we're doing it in the activesupport rpm (and all other rails rpms starting w/ 3.0.3)
http://mo.morsi.org/files/rpms/rubygem-activesupport.spec
As always, additional thoughts and improvements are welcome.
I know, I saw the activesupport. However I believe:
- The package should be as close to upstream as possible, therefore I
am reluctant to keep the test in the rpm. 2) User of the library doesn't care about tests, because he relays on the author of the library and on packager. Although test can be viewed as a documentation, I believe that most of the users will prefer other ways how to reach it (rdoc.info, github). So again, the test are just occupying space on your hard drive.
But since this is philosophical topic, I would love to hear some opinion from others.
Yes I agree. The guidelines don't say anything on the matter, so its really up to the packager, and it doesn't either way with or without the tests included in the final package, so long as they are being run to verify the package works when its built. If space is a concern, the tests can always go into a seperate docs subpackage as well.
One more downside is that RSpec are usually defined just as a build time dependency, therefore it is not ensured that user can run the specs anyway.
If the tests / specs are marked as %doc, we do not need to introduce a rspec runtime dependency.
-Mo
ruby-sig@lists.fedoraproject.org