Prev: how to redirect to a url that is stored inside a variable
Next: Using variables defined in configuration files
From: Intransition on 20 Apr 2010 11:00
On Apr 20, 3:35 am, Christian Neukirchen <chneukirc...(a)gmail.com>
wrote:
> Hello,
>
> earlier this month I wrote up a draft for a specification on how to
> structure Ruby projects.  It started athttp://gist.github.com/361451
> and there was lots of discussion there, which I now want to move to
> ruby-talk to gain a larger audience.
>
> The specification now resides at
>
>                  http://chneukirchen.github.com/rps/
>
> and is generated fromhttp://github.com/chneukirchen/rps.
>
> Please keep discussion on RPS to this thread, so people which usually
> don't follow ruby-talk can discuss too.

I don't understand. Do you want us to discuss it here or not?

From: Intransition on 20 Apr 2010 15:05


On Apr 20, 12:35 pm, Joel VanderWerf <joelvanderw...(a)gmail.com> wrote:
> Intransition wrote:
> > 1) Change "Executables SHOULD NOT require 'rubygems' or modify the
> > $LOAD_PATH" to a "MUST NOT". There's no reason to do this in an
> > executable.
>
> Except for the _gem_ executable itself, or any other executable that
> needs to operate on gems. SHOULD NOT was the right call.

Clearly the gem command itself is necessary exception --it *is*
rubygems. I would suggest any other library that "operates on gems"
still use a lib/ file and require that in their executable. But the
rule applies even in lib/, so here again it is an exceptional case
when one is specifically extending/augmenting rubygems. The rules
intent is to address all other cases. So perhaps the best phrasing is
still "MUST" but with a qualification concerning libraries designed
for extending/augmenting rubygems.

From: Intransition on 20 Apr 2010 11:33
On Apr 20, 11:00 am, Intransition <transf...(a)gmail.com> wrote:
> I don't understand. Do you want us to discuss it here or not?

Ok. Just read last post from github and it indicates to discuss here.
Also, I noticed the the Google archive knocked off the [RFC] portion
of the subject. Hope that's not problem.

From: Intransition on 20 Apr 2010 11:58
In response josh and zimbatm regarding setup.rb.

I carried on development of that project here: http://proutils.github.com/setup.
It can now run as ordinary bin, or, of course, it can be included as a
project script when specifically necessary.

Point responses to zimbatm's post

> * data/ is copied in #{PREFIX_DIR}/share (like /usr/share). Why not name it "share" then ?

I would agree, but rbconfig.rb refers to it as 'datadir'.

> * conf/ is copied in /etc. Why not name it "etc" then ?

The latest versions of setup.rb have renamed that to etc/.

> * setup.rb multi-project layout is probably a bad idea. Package management should handle this

Latest versions of setup.rb no longer support multi-project layout.

The most problematic issue I had with working on setup.rb was with
documentation. FHS standards would indicate that the packages
documentation be copied to /usr/share/doc/{name}/ (using standard
system prefix), However, unless Ruby projects use doc/{name}/ (just
like lib/{name}/) then it's not very feasible b/c there is no standard
way to get the name of the project. Right now it looks in
either .setup/name or .meta/name (or without dot) as a stop-gap
measure for lack of any other option. If anything comes out this
process, beyond just writing down current common practices, maybe it
would be this doc/{name}/ convention.

On the other hand, maybe it's time to give setup.rb and the whole FHS
style of program installation the kiss of death.

From: Intransition on 20 Apr 2010 12:23
Final comments for now, I promise ;-)

1) Change "Executables SHOULD NOT require 'rubygems' or modify the
$LOAD_PATH" to a "MUST NOT". There's no reason to do this in an
executable.

2) Change "Libraries SHOULD NOT require code of the project that are
outside of lib/" and "Executables SHOULD NOT require code of the
project that are outside of lib/" to a "MUST NOT". Otherwise other
package mangers like setup.rb and rip will not work.

3) I have basically given up on using data/ directory. I now put all
such files in lib/. It is much easier to use relative lookup then to
use rbconfig.rb and Config::CONFIG['datadir']. While some think this
is a "no no", I don't see any worthy advantage of using data/. I know
the noble idea is that data/ is then accessible by other libraries,
but honestly it almost never happens. In a case where it is likely,
then ok use data/, but I don't think it should be mandatory. So I
suggest removing "Ruby library files MUST end with .rb." altogether.

4) Test locations might be a little too framework-oriented for any
kind of RPS. Test::Unit and MiniTest use test/, RSpec used spec/,
Cucumber uses features/. I ran into this question when developing QED
and in the end I just settled for qed/.

 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: how to redirect to a url that is stored inside a variable
Next: Using variables defined in configuration files