On Wed, Apr 21, 2010 at 9:36 AM, Suraj K. [email protected]
wrote:
My concern is about the Ruby code in bin/ and lib/ being able to
find the rest of the files that originally came in the package. Â If
this RPS would define that related-file-finding code, then I don’t
need to reinvent it (or copy/paste) for all of my Ruby libraries.
Isn’t that precisely what Config::CONFIG[‘datadir’] is for?
On Apr 21, 2:07 pm, Damian J. [email protected] wrote:
[…]
Under Tests, should there be a standard for running the entire test
suite? Say,rake?
That would trigger other dependencies developers might have in their
rake tasks (like coverage, documentation, mutation testing, etc.)
I simple “ruby -Ilib test/test*.rb” should suffice, right?
On Tue, Apr 20, 2010 at 4:35 AM, Christian N.
[email protected] wrote:
Hello,
earlier this month I wrote up a draft for a specification on how to
structure Ruby projects. It started at RPS-SPEC · GitHub
and there was lots of discussion there, which I now want to move to
ruby-talk to gain a larger audience.
Under Tests, should there be a standard for running the entire test
suite? Say, rake?
Luis L. wrote:
On Apr 21, 2:07 pm, Damian J. [email protected] wrote:
[…]
Under Tests, should there be a standard for running the entire test
suite? Say,rake?That would trigger other dependencies developers might have in their
rake tasks (like coverage, documentation, mutation testing, etc.)I simple “ruby -Ilib test/test*.rb” should suffice, right?
I have some Rakefiles where the default task is to list the tasks.
In other cases a I set it to run the test tool of choice (sometimes
bacon, something rspec, it varies).
If I were to want a default default (so to speak) I’d prefer the task
listing rather than kicking off something. It’s easy enough to change
to suit one’s personal preferences.
Or leave the Rakefile with no default task.
–
James B.
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development
On Apr 21, 2010, at 3:48 PM, James B. wrote:
If I were to want a default default (so to speak) I’d prefer the task listing rather than kicking off something.
I don’t think I’m for recommending a default, but listing the tasks
definitely wouldn’t be my first choice. That’s a function of Rake
itself (rake -T), so I would hate to waste a task on it. That’s just my
opinion.
James Edward G. II
On Apr 21, 2:50 pm, Luis L. [email protected] wrote:
I simple “ruby -Ilib test/test*.rb” should suffice, right?
Depends on the testing framework. Some do not support autorun. Some
tests aren’t located in test/. For most ‘rake test’ is the common
practice, but as someone who does not use rake I have at times
wondered how best to approach this myself. It’s not a huge issue
really, since only developers tend to actually run the tests and
whatever system used it’s not too hard for developers to figure out.
On occasion though I have provided a ruby executable called ‘script/
test’ to handle it.
James Edward G. II wrote:
On Apr 21, 2010, at 3:48 PM, James B. wrote:
If I were to want a default default (so to speak) I’d prefer the task listing rather than kicking off something.
I don’t think I’m for recommending a default, but listing the tasks definitely wouldn’t be my first choice. That’s a function of Rake itself (rake -T), so I would hate to waste a task on it. That’s just my opinion.
Yeah, it’s not like it isn’t already there, it’s just that if I type
‘rake’, I’d rather something useful but benign happen instead of a
message about there being no ‘default’ defined.
But either way I don’t want to inadvertently kick off some potentially
lengthy process.
–
James B.
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development
All,
The purpose of Christian’s is to provide a minimal, consistent, and
tool agnostic set of guidelines for organizing your Ruby library. If
the changes or additions you’re suggesting assume the presence of any
tool other than Ruby itself, you’re almost certainly bikeshedding.
Please give your suggestions some heavy thought before posting.
~ j.
On Apr 20, 3:20 pm, Luis L. [email protected] wrote:
- “Extensions SHOULD be buildable with ruby extconf.rb; make.”
That is not true, there are extension that even using extconf they
generate Rakefiles, because they depend on mkrf and not mkmfThat can’t be enforced on these developers, if done a lot of project
could break.
I’d like to see mkrf formally spec’d here. I’m not to familiar with
mkrf or know to many gems using it. Do you still use extconf.rb but
require mkrf instead?
Also, whats your opinion on make + copy vs “make install” with
sitearchdir. Both seem to be compatible with all Makefiles generated
with mkmf. The problem with copying is that you have to manually
extract the target_prefix from the Makefile.
Thomas S. wrote:
I feel that the FHS has become largely arcane. If I had
my druthers I’d much rather see the Ruby community make a concerted
motion toward throwing setup.rb/FHS support right out on it’s arse.
Hurray! Well said. +1 
As far as shared data and configuration goes, btw, when it is needed,
the XDG directory standard offers a much better approach.
Here’s a link about XDG-DS in Ruby context for lazy people like myself:
Cheers.
On Apr 21, 2:06 am, Lucas N. [email protected] wrote:
I’m not sure I understand your point. The point of setup.rb is to
respect FHS, which contradicts installing everything in the same place.
But the starting point of a setup.rb installation is the same as a
well-organized gem: if you put executables in bin/, libraries in lib/,
etc, it just works.
All true. But it does effect how one is able to access files from
other files within a package, e.g. relative requires. If it were not
for the limitations that the FHS design brings to bare we would have
many fewer rules and worries.
My personal opinion falls in line with Hisham H. Muhammad’s in I am not
clueless. I feel that the FHS has become largely arcane. If I had
my druthers I’d much rather see the Ruby community make a concerted
motion toward throwing setup.rb/FHS support right out on it’s arse.
And that’s despite the fact that I personally spent considerable time
modernizing the setup.rb code base. I believe the FHS is largely
holding back progress in this area. Both Windows and MacOS X use
directory package models. Linux lags behind primarily b/c it is a open/
democratic system tied to entrenched customs. As such, it can not be
changed from the top down. The change must come from the bottom up –
which is much harder to do. I think scripting languages and their
modern packaging systems, like RubyGems, are (no doubt inadvertently)
leading the way in this “quiet” revolution. Hisham si one of few
people that I think sees the writing on the wall is preparing for it
(see Home - Michael Homer)
As far as shared data and configuration goes, btw, when it is needed,
the XDG directory standard offers a much better approach.
On Apr 22, 2:14 pm, Suraj K. [email protected] wrote:
Here’s a link aboutXDG-DS in Ruby context for lazy people like myself:
Project has since moved to GitHub:
GitHub - rubyworks/xdg: XDG Base Directory Standard Library for Ruby
http://rubyworks.github.com/xdg
Thomas S. wrote:
Suraj K. wrote:
Project has since moved to GitHub:
GitHub - rubyworks/xdg: XDG Base Directory Standard Library for Ruby
http://rubyworks.github.com/xdg
Thanks for the update. For posterity, I suggest
adding a .htaccess to the old RubyForge site thus:
RedirectPermanent / http://rubyworks.github.com/xdg
Cheers.
How the Config.datadir(‘$projectname’) pattern is supposed to be used
during say a development of a gem?
On Apr 20, 11:27 am, Christian N. [email protected]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs