[ANN] [RFC] Proposing a Ruby Packaging Standard

ruby-talk
21

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.

···

On Apr 21, 2:50 pm, Luis Lavena <luislav...@gmail.com> wrote:

On Apr 21, 2:07 pm, Damian Janowski <damian.janow...@gmail.com> 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?

22

Luis Lavena 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.

···

On Apr 21, 2:07 pm, Damian Janowski <damian.janow...@gmail.com> wrote:

--
James Britt

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

23

I think that what is important is that we have a clear set of guidelines
for Ruby library developers to follow, that allow to do both
rubygems-style stuff and setup.rb-style stuff. The goal of this
"standard" should not be to push one or the other solution.

···

On 21/04/10 at 14:01 +0900, Suraj Kurapati wrote:

Thomas Sawyer wrote:
> On Apr 20, 1:12 pm, Suraj Kurapati <sun...@gmail.com> wrote:
>> find my project's man/ directory from my project's executable in bin/!
>
> The standard approach would be something like:
>
> require 'rbconfig'
> dir = Config::CONFIG['datadir']
> file = File.join(dir, 'man/man1/ember.1')

Thanks. Based on this example, I found that there is a
Config::CONFIG['mandir'] which tells us exactly where the
system's man/ directory is located.

> B/c of RubyGems there is an extension method that redirects to the the
> appropriate place.
>
> Config.datadir("ember")

RubyGems does not seem to provide that functionality on my system:

    sun@yantram ~> irb
    ## ruby 1.9.1p378 (2010-01-10 revision 26273) [i686-linux]
    >> require 'rbconfig'
    => true
    >> Config.datadir("ember")
    NoMethodError: undefined method `datadir' for RbConfig:Module
            from (irb):2
            from /usr/bin/irb:12:in `<main>'
    >> require 'rubygems'
    => false
    >> Config.datadir("ember")
    NoMethodError: undefined method `datadir' for RbConfig:Module
            from (irb):4
            from /usr/bin/irb:12:in `<main>'
    >> Gem::VERSION
    => "1.3.6"

> But I think it might be a problem to tell which is which for locating
> the man/ directory.

I guess RubyGems provides a Config.mandir(the_gem_name) method to do
this?

>> Also, if I provide a man/ directory in my gem/tarball package like this:
>>
>> man/
>> └── man1
>> ├── ember.1
>> └── ember.1.html
>
> Can man handle .html?

Nope. That's just there as a backup, in case a user is on Windoze
or their system somehow lacks the `man` command. `man` does warn me
about it though when searching for manpages in my man/ directory:

    man: warning: man/man1/ember.1.html: ignoring bogus filename

But I think it's worthy trade-off to have a HTML version available.

> I glanced at the entries in my system and I
> noticed they are all gzipped (ending in .gz).

Thanks for the tip. I've gzipped my Roff manpage now.

>> Will it be copied into /usr/share/man/ by RubyGems/setup.rb/Rip and
>> friends?
>
> Setup.rb does. RubyGems does not. Not sure about Rip.

Will RubyGems ever follow the FHS style of installation like setup.rb?

Will setup.rb ever follow the keep-everything-together RubyGems style?

What installation style will this Ruby Packaging Standard follow?

So many questions... Life was easier when I only used RubyGems. :-/

--

Lucas Nussbaum
lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |

24

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 Gray II

···

On Apr 21, 2010, at 3:48 PM, James Britt wrote:

If I were to want a default default (so to speak) I'd prefer the task listing rather than kicking off something.

25

Lucas Nussbaum wrote:

Will RubyGems ever follow the FHS style of installation like setup.rb?
Will setup.rb ever follow the keep-everything-together RubyGems style?
What installation style will this Ruby Packaging Standard follow?

I think that what is important is that we have a clear set of
guidelines for Ruby library developers to follow, that allow to do
both rubygems-style stuff and setup.rb-style stuff.

It's burdensome on Ruby library developers to support both ways.

Perhaps this Ruby Packaging Standard could provide a tiny Ruby
library to ease that burden, by making the FHS/setup.rb style
installation appear like RubyGems style installation (i.e. how all
files are organized inside a release package and when checked out
from a source code repository)?

The goal of this "standard" should not be to push one or the other
solution.

Good point. Thanks for clarifying this.

···

On 21/04/10 at 14:01 +0900, Suraj Kurapati wrote:

--
Posted via http://www.ruby-forum.com/\.

26

James Edward Gray II wrote:

···

On Apr 21, 2010, at 3:48 PM, James Britt 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 Britt

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

27

Lucas Nussbaum wrote:
>> Will RubyGems ever follow the FHS style of installation like setup.rb?
>> Will setup.rb ever follow the keep-everything-together RubyGems style?
>> What installation style will this Ruby Packaging Standard follow?
>
> I think that what is important is that we have a clear set of
> guidelines for Ruby library developers to follow, that allow to do
> both rubygems-style stuff and setup.rb-style stuff.

It's burdensome on Ruby library developers to support both ways.

Not really. Both solutions are largely compatible. You just need to
organize the files correctly, and it just works.

Perhaps this Ruby Packaging Standard could provide a tiny Ruby
library to ease that burden, by making the FHS/setup.rb style
installation appear like RubyGems style installation (i.e. how all
files are organized inside a release package and when checked out
from a source code repository)?

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.

···

On 21/04/10 at 14:55 +0900, Suraj Kurapati wrote:

> On 21/04/10 at 14:01 +0900, Suraj Kurapati wrote:

--

Lucas Nussbaum
lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |

28

Lucas Nussbaum wrote:

···

On 21/04/10 at 14:55 +0900, Suraj Kurapati wrote:

Perhaps this Ruby Packaging Standard could provide a tiny Ruby
library [...] making the FHS/setup.rb style installation appear
like RubyGems style installation

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.

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.
--
Posted via http://www.ruby-forum.com/\.

29

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 <a
href="GoboLinux - the alternative Linux distribution am not
clueless</a>. 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 http://mwh.geek.nz/2009/07/23/an-overview-of-systemaliens/\)

As far as shared data and configuration goes, btw, when it is needed,
the XDG directory standard offers a much better approach.

···

On Apr 21, 2:06 am, Lucas Nussbaum <lu...@lucas-nussbaum.net> 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.

30

Isn't that precisely what Config::CONFIG['datadir'] is for?

···

On Wed, Apr 21, 2010 at 9:36 AM, Suraj Kurapati <sunaku@gmail.com> 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.

--
Dmitry Borodaenko

31

Thomas Sawyer 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 :slight_smile:

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:

   http://xdg.rubyforge.org/

Cheers.

···

--
Posted via http://www.ruby-forum.com/\.

32

Dmitry Borodaenko 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.

Isn't that precisely what Config::CONFIG['datadir'] is for?

Yes, but that value does not reflect RubyGems style on my system:

  >> Config::CONFIG['datadir']
  => "/usr/share"

  >> `gem env`.lines.grep(/install/i)
  => [" - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.9.1\n"]

It needs to reflect both styles to work correctly under either one.

I am using RubyGems 1.3.6 with Ruby 1.9.1p378 on i686-linux.

···

On Wed, Apr 21, 2010 at 9:36 AM, Suraj Kurapati <sunaku@gmail.com> > wrote:

--
Posted via http://www.ruby-forum.com/\.

33

Project has since moved to GitHub:

   GitHub - rubyworks/xdg: XDG Base Directory Standard Library for Ruby
   http://rubyworks.github.com/xdg

···

On Apr 22, 2:14 pm, Suraj Kurapati <sun...@gmail.com> wrote:

Thomas Sawyer 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 :slight_smile:

> As far as shared data and configuration goes, btw, when it is needed,
> theXDGdirectory standard offers a much better approach.

Here's a link aboutXDG-DS in Ruby context for lazy people like myself:

http://xdg.rubyforge.org/

34

Thomas Sawyer wrote:

Suraj Kurapati wrote:

  http://xdg.rubyforge.org/

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.

···

--
Posted via http://www.ruby-forum.com/\.