Best way to release mini-libraries?

[Kirk Haines]

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

 

[Trans]

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]

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.

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 store= s
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.
=20
Both of these were originally part of IOWA, but have been recently conver= ted
into standalone libraries. Should they get their own projects at Rubyfor= ge,
or should I just hang them off the IOWA project a seperate download?
=20
Opinions?
=20
=20
Kirk Haines
=20
=20

--=20
BlueSteel | | Merkoth

 

[Austin Ziegler]

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 store= s
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.
=20
Both of these were originally part of IOWA, but have been recently conver= ted
into standalone libraries. Should they get their own projects at Rubyfor= ge,
or should I just hang them off the IOWA project a seperate download?

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
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Kirk Haines]

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:bPool. 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

 

[Aredridel]

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:bPool. 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]

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

 

[Austin Ziegler]

Okay, now, a related question.
=20
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:bPool. 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.
=20
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?

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 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
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)