Best way to release mini-libraries?

(Kirk Haines) #1

I have several tidbits here and there which are part of a larger project, but
which are useful on their own. These include a webcache class that stores
content in an LRU and tries to do the right thing regarding expired, etag,
and last_modified HTTP header items, and a library built around tmail to make
sending MIME emails easier.

Both of these were originally part of IOWA, but have been recently converted
into standalone libraries. Should they get their own projects at Rubyforge,
or should I just hang them off the IOWA project a seperate download?

Opinions?

Kirk Haines

(7rans) #2

Hi--

I have a pretty sizable project that is a collection of just such
useful "mini-libs". Would you like to host them there? I'd be very
happy to consder them.

T.

(Ivan Vodopiviz) #3

I think the best idea is to host them in the same project page. That
way people will know that the libraries are part of IOWA. Just make
sure that ppl doesn't get confused with too many different file
releases.

···

On 8/29/05, Kirk Haines <khaines@enigo.com> wrote:

I have several tidbits here and there which are part of a larger project, but
which are useful on their own. These include a webcache class that stores
content in an LRU and tries to do the right thing regarding expired, etag,
and last_modified HTTP header items, and a library built around tmail to make
sending MIME emails easier.

Both of these were originally part of IOWA, but have been recently converted
into standalone libraries. Should they get their own projects at Rubyforge,
or should I just hang them off the IOWA project a seperate download?

Opinions?

Kirk Haines

--
BlueSteel | | Merkoth

(Austin Ziegler) #4

I would do the latter. That's more or less what I've done with both
Ruwiki and PDF::Writer as I've added mini-libs there, until those libs
grow up enough to demand their own space (which, so far, none of them
have ;).

-austin

···

On 8/29/05, Kirk Haines <khaines@enigo.com> wrote:

I have several tidbits here and there which are part of a larger project, but
which are useful on their own. These include a webcache class that stores
content in an LRU and tries to do the right thing regarding expired, etag,
and last_modified HTTP header items, and a library built around tmail to make
sending MIME emails easier.

Both of these were originally part of IOWA, but have been recently converted
into standalone libraries. Should they get their own projects at Rubyforge,
or should I just hang them off the IOWA project a seperate download?

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

(Kirk Haines) #5

Okay, now, a related question.

I'm a bit paranoid about namespace pollution. So, everything that goes into
IOWA is in an Iowa:: namespace. So, the database connection pool is
Iowa::DbPool. The web cache class is Iowa::Webcache and the LRU class that
it uses is Iowa::LRUCache. And so on.

Does anyone see any problem with keeping these in that Iowa:: namespace when
released as standalone libraries? Keeping, for example, the webcache, under
Iowa:: makes sure that it won't butt heads with someone else's web cache.
Just calling it 'class Webcache', though, would.

Or should it be released as nothing more than a class file without any
installer, leaving it up to the user to make sure it doesn't butt heads with
something else? Anyone out there who might use this who has an opinion?

Thanks,

Kirk Haines

···

On Monday 29 August 2005 8:41 am, Austin Ziegler wrote:

I would do the latter. That's more or less what I've done with both
Ruwiki and PDF::Writer as I've added mini-libs there, until those libs
grow up enough to demand their own space (which, so far, none of them
have ;).

(Aredridel) #6

I'm a bit paranoid about namespace pollution. So, everything that goes into
IOWA is in an Iowa:: namespace. So, the database connection pool is
Iowa::DbPool. The web cache class is Iowa::Webcache and the LRU class that
it uses is Iowa::LRUCache. And so on.

Does anyone see any problem with keeping these in that Iowa:: namespace when
released as standalone libraries? Keeping, for example, the webcache, under
Iowa:: makes sure that it won't butt heads with someone else's web cache.
Just calling it 'class Webcache', though, would.

Or should it be released as nothing more than a class file without any
installer, leaving it up to the user to make sure it doesn't butt heads with
something else? Anyone out there who might use this who has an opinion?

My first thought is to keep it in Iowa:: if it's going to stay in synch
with Iowa versions, and to make it separate if it's going to diverge.

Ari

(David Brady) #7

Kirk Haines wrote:

Or should it be released as nothing more than a class file without any installer, leaving it up to the user to make sure it doesn't butt heads with something else? Anyone out there who might use this who has an opinion?

If I can include it with

require 'webcache'

I would expect Webcache.new to work.

If I have to include it with

require 'iowa/webcache'

I would expect to have to prefix Iowa:: to the namespace. This would also imply to me that it isn't really standalone....

I'm not a Ruby authority by any means; is it possible to grab a naked module (e.g. something that imports directly into your namespace) and wrap it in a module? If so, then your fear of polluting the namespace is overcautious. This doesn't work, but you can see my intent:

···

------------------------------
class Webcache
  #...our Webcache class
end

# Iowa's Webcache imports directly, conflicting with our Webcache
# class. Wrap it in IowaWebcache
module IowaWebcache
  # this doesn't work--require seems to import directly into top-level space
  require 'webcache'
end

w1 = Webcache.new
w2 = IowaWebcache::Webcache.new
------------------------------

Related:
- How can you achieve the desired result above, i.e. pushing an existing module down into another module?
- How can you reverse it, importing the contents of a module into the current namespace? (e.g. Python's "import from" syntax)

If the end-user can manipulate the modules and namespaces freely, then my suggestion is to put the code in the most *convenient* place possible. Later users can pack it away in another namespace if they feel the need.

-dB

--
David Brady
ruby-talk@shinybit.com
Grizzled C++/Python/Perl hacker. New to Ruby. Take my Ruby statements with the appropriate amount of salt.
I'm having a really surreal day... OR AM I?

(Austin Ziegler) #8

That's a bit of a good question, and I'm not the *best* person to ask,
as I have claimed a couple of high-level namespaces :wink: The simple answer
is "it depends."

* With MIME::Types, I basically claimed MIME::Type and MIME::Types and
  forced ::MIME to be a module if anyone uses it. (But that's not a
  subproject. However, if I ever *do* get around to doing the libmagic
  stuff, it'll probably be MIME::Magic.)
* With Diff::LCS, I forced Diff to be a module, but chose to be more
  specific.
* I went further with Archive::Tar::Minitar (obviously).
* PDF::Writer is perhaps the biggest claim, and it's not going to get
  much better unless I come up with a cool project name to replace it. I
  will be releasing PDF::Core, PDF::Writer, and PDF::Reader, all. I have
  several utility items (PDF::Charts::*, PDF::SimpleTable, etc.) that
  have sort of claimed space.
* color-tools has claimed the entire Color namespace (which, frankly, I
  don't mind ;), but makes it a bit harder for others to use ::Color as
  anything other than a module, and I "own" Color::RGB and Color::CMYK
  and others as a result of it.

I can't see having done any of these any other way, though, since
although color-tools was originally made to support PDF::Writer, I want
it to be the premier colour conversion and management library in the
Ruby world.

On the other hand, I'm working on a different library (also an offshoot
of PDF::Writer) that I've chosen an entirely different name for (and
even that may change if someone takes the name I've chosen or I find a
better one).

-austin

···

On 8/29/05, Kirk Haines <khaines@enigo.com> wrote:

On Monday 29 August 2005 8:41 am, Austin Ziegler wrote:

I would do the latter. That's more or less what I've done with both
Ruwiki and PDF::Writer as I've added mini-libs there, until those
libs grow up enough to demand their own space (which, so far, none of
them have ;).

Okay, now, a related question.

I'm a bit paranoid about namespace pollution. So, everything that
goes into IOWA is in an Iowa:: namespace. So, the database connection
pool is Iowa::DbPool. The web cache class is Iowa::Webcache and the
LRU class that it uses is Iowa::LRUCache. And so on.

Does anyone see any problem with keeping these in that Iowa::
namespace when released as standalone libraries? Keeping, for
example, the webcache, under Iowa:: makes sure that it won't butt
heads with someone else's web cache. Just calling it 'class Webcache',
though, would.

Or should it be released as nothing more than a class file without any
installer, leaving it up to the user to make sure it doesn't butt
heads with something else? Anyone out there who might use this who
has an opinion?

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca