Plugin best practices
 

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

Re: Plugin best practices
 

On Wed, Jun 15, 2011 at 11:36 AM, Intransition <transfire@gmail.com> wrote:
>
> 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

Re: Plugin best practices
 

On Wed, Jun 15, 2011 at 4:36 AM, Intransition <transfire@gmail.com> wrote:

> 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/...es_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

Re: Plugin best practices
 

On Jun 15, 7:37=A0am, Josh Cheek <josh.ch...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 4:36 AM, Intransition <transf...@gmail.com> wrote=
:
> > 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,
>
> > =A0 =A0lib/rdoc-foo.rb
>
> > Or
>
> > =A0 =A0lib/rdoc/foo.rb
>
> According to both of the resources I'd reference, it should be the latter=

Re: Plugin best practices
 

On Jun 15, 2011, at 5:33 AM, Intransition wrote:
> 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.=

Re: Plugin best practices
 

On Jun 15, 4:33=A0pm, Eric Hodel <drbr...@segment7.net> wrote:
> On Jun 15, 2011, at 5:33 AM, Intransition wrote:
>
> > Yea, I was afraid you would say that ;-)
>
> > 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? =A0Is=
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 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.