Plugin best practices

Discussion in 'Ruby' started by Intransition, Jun 15, 2011.

  1. Intransition

    Intransition Guest

    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
     
    Intransition, Jun 15, 2011
    #1
    1. Advertising

  2. On Wed, Jun 15, 2011 at 11:36 AM, Intransition <> 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
     
    Phillip Gawlowski, Jun 15, 2011
    #2
    1. Advertising

  3. Intransition

    Josh Cheek Guest

    On Wed, Jun 15, 2011 at 4:36 AM, Intransition <> 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/#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
     
    Josh Cheek, Jun 15, 2011
    #3
  4. Intransition

    Intransition Guest

    On Jun 15, 7:37=A0am, Josh Cheek <> wrote:
    > On Wed, Jun 15, 2011 at 4:36 AM, Intransition <> 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=
     
    Intransition, Jun 15, 2011
    #4
  5. Intransition

    Eric Hodel Guest

    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.=
     
    Eric Hodel, Jun 15, 2011
    #5
  6. Intransition

    Intransition Guest

    On Jun 15, 4:33=A0pm, Eric Hodel <> 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.
     
    Intransition, Jun 16, 2011
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. karim
    Replies:
    0
    Views:
    470
    karim
    Jul 13, 2003
  2. John Dalberg
    Replies:
    3
    Views:
    578
    samuelhon
    Nov 16, 2006
  3. Flavio
    Replies:
    8
    Views:
    307
    Flavio
    Feb 22, 2007
  4. Jean-Paul Calderone

    Re: plugin development best practices

    Jean-Paul Calderone, Feb 22, 2007, in forum: Python
    Replies:
    3
    Views:
    293
    Flavio
    Feb 22, 2007
  5. Chicken McNuggets

    Best book on C gotchas and best practices?

    Chicken McNuggets, Jul 31, 2013, in forum: C Programming
    Replies:
    9
    Views:
    270
    Fred J. Tydeman
    Aug 5, 2013
Loading...

Share This Page