Plugin best practices

I

Intransition

If your making a plugin/extension for another project, do you create a
hyphenated lib file or do you put the library file in a subdirectory,
e.g. say it's a plugin for rdoc,

lib/rdoc-foo.rb

Or

lib/rdoc/foo.rb
 
P

Phillip Gawlowski

If your making a plugin/extension for another project, do you create a
hyphenated lib file or do you put the library file in a subdirectory,

I'd follow project conventions of how code is organized. If they do
project/foo-lib.rb, I do that. If they do project/foo/lib.rb, I do
that.

If there is no discernible pattern, I'd go with project/plugin/foo/lib.rb.

--=20
Phillip Gawlowski

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Leibnitz
 
J

Josh Cheek

If your making a plugin/extension for another project, do you create a
hyphenated lib file or do you put the library file in a subdirectory,
e.g. say it's a plugin for rdoc,

lib/rdoc-foo.rb

Or

lib/rdoc/foo.rb
According to both of the resources I'd reference, it should be the latter.


=3D=3D=3D=3D=3D http://guides.rubygems.org/patterns/#use_dashes_for_extens=
ions =3D=3D=3D=3D=3D

Adding new functionality to an existing gem? Use a dash. Some examples
include net-http-persistent and autotest-growl. Usually this implies that
you=92ll have to require into their directory tree as well. For example, `g=
em
install net-http-persistent` becomes `require 'net/http/persistent'`.




=3D=3D=3D=3D=3D http://chneukirchen.github.com/rps/ =3D=3D=3D=3D=3D

Project names SHOULD only contain underscores as separators in their
names. If a project is an enhancement, plugin, extension, etc. for some
other project it SHOULD contain a dash in the name between the original nam=
e
and the project=92s name. File names and directory structure SHOULD corresp=
ond
like this:

Library: foo-bar
Directory: lib/foo/bar
Namespace: Foo::Bar

Library: foo_bar
Directory: lib/foo_bar
Namespace: FooBar
 
E

Eric Hodel

Yea, I was afraid you would say that ;-)
=20
Technically speaking this is a bad idea. The reason is that if someone
wanted to install a project in the traditional site ruby locations
(e.g. via setup.rb),

(How many ruby packages have a setup.rb anymore, and who uses them? Is =
it even 5% of rubyists? 1%?)
then there is the potential for file name
conflicts such that the last package installed will clobber the file
from a previous package.

If everybody agreed to foo-bar.rb instead of foo/bar.rb that wouldn't =
solve the problem as they both share the same name.

Giving two implementations the same file name is a social problem, not a =
technical problem. We can't solve this with a technical solution.=
 
I

Intransition

(How many ruby packages have a setup.rb anymore, and who uses them? =A0Is= it even 5% of rubyists? 1%?)


If everybody agreed to foo-bar.rb instead of foo/bar.rb that wouldn't sol=
ve the problem as they both share the same name.
Giving two implementations the same file name is a social problem, not a =
technical problem. =A0We can't solve this with a technical solution.

If my plugin for `foo` is `bar` then my lib file will be `foo-bar.rb`
and my gem's name `foo-bar`. So you won't have the same name, because
I already have that gem. Clearly your gem and require will be `foo-
baz`. No clash.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top