What to do with the snippets of code you always use?

I have a question on maintaining code.
While coding several scripts and a couple of libraries, I developed some snippets I keep using over and over. Things like a parseCommandline method with the standard switches I normally use to be extended for each script, a couple of methods that I always use to initialize Logger, stuff like that.
Mostly these form part of my idiomatic use of Ruby and I keep improving on them as I learn, so it makes sense to keep them separate as a library and version them for my own sake, but they do not form a releaseable library - everyone has his favorite idiom.
Now, as I said, I use these snippets everywhere, so obviously when I want to release something I need to include the "private" library.
Up until now, I was lumping all this code in a file together with the script/library that was the main subject.
What would be the best way to maintain the snippet code and use it all over?
I tend towards the solution of grabing the latest version of my "private" lib out of my repository and building a gem for the actual 'product' then distribute that.
Local development requires that I install my snippet lib as a gem or in ruby/lib in my development box, but I can live with that (it forces me to play nice with versions too).
Any other ideas?
V.-

···

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

i do this

   http://www.codeforpeople.com/lib/ruby/alib/

note that the libs are versioned, therefore i can write

   require 'alib-0.1.0'

in a script and install new versions as i learn/add without breaking existing
scripts. for convenience i also have link installed so

   require 'alib'

gets the latest version.

cheers.

-a

···

On Thu, 22 Sep 2005, Damphyr wrote:

I have a question on maintaining code. While coding several scripts and a
couple of libraries, I developed some snippets I keep using over and over.
Things like a parseCommandline method with the standard switches I normally
use to be extended for each script, a couple of methods that I always use to
initialize Logger, stuff like that. Mostly these form part of my idiomatic
use of Ruby and I keep improving on them as I learn, so it makes sense to
keep them separate as a library and version them for my own sake, but they
do not form a releaseable library - everyone has his favorite idiom. Now,
as I said, I use these snippets everywhere, so obviously when I want to
release something I need to include the "private" library. Up until now, I
was lumping all this code in a file together with the script/library that
was the main subject. What would be the best way to maintain the snippet
code and use it all over? I tend towards the solution of grabing the latest
version of my "private" lib out of my repository and building a gem for the
actual 'product' then distribute that. Local development requires that I
install my snippet lib as a gem or in ruby/lib in my development box, but I
can live with that (it forces me to play nice with versions too).
Any other ideas?
V.-

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

Ara.T.Howard wrote:

I have a question on maintaining code. While coding several
scripts

snip

version of my "private" lib out of my repository and building a gem
for the actual 'product' then distribute that. Local development
requires that I install my snippet lib as a gem or in ruby/lib in
my development box, but I can live with that (it forces me to play
nice with versions too). Any other ideas? V.-

i do this

http://www.codeforpeople.com/lib/ruby/alib/

note that the libs are versioned, therefore i can write

require 'alib-0.1.0'

in a script and install new versions as i learn/add without breaking
existing scripts. for convenience i also have link installed so
require 'alib'
gets the latest version.

Well I assume you do that for yourself locally. What do you do when distributing something that uses alib?
When having application A and application B use alib do you distribute one copy of the alib files with each app or do you require someone to install alib?
I am reluctant to require installation of a "private" library be it tar or gem. I prefer using a rakefile to grab the appropriate files and bundle them together with the app (which adds a reusable rake task definition to the lib :slight_smile: ).
So my box has the library installed complete with versioning and the app gets a copy to be used from '.'.
One major drawback of this approach is when drastic changes in the "private" library break the applications - releasing bugfixes for the app requires updating to the current version of the lib.
You use versioning in the library, for the moment I use my source control system to keep the versions aligned.
I guess what I am formulating is the desire to handle my snippets like a separate project internally, but distribute them as integral pieces of each application.
V.-

···

On Thu, 22 Sep 2005, Damphyr wrote:

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

all issues i've considered. some observations:

   - making a library for public consumption generally makes you think harder
     and make better choices regarding backward compatibility. this is a good
     thing.

   - inlining a lib everywhere violate dry is such a massive way it's not
     funny. i used to do this and then ended up with 17 micro versions that
     all needed fixing when a serious bug was found. this is bad. evil in
     fact.

there's no good answer i guess. the former (maintaining a library) just seems
less bad. i often walk the middle and include a copy of my lib in a depends/
subdir of a release, that way at least it's easy to find. another approach i
sometimes take is

   begin
     require LIBDIR + 'alib-0.0.0'
   rescue LoadError
     begin
       require 'alib-0.0.0'
     rescue LoadError
       require 'alib'
     end
   end

so, try the local lib, installed lib of the correct version. then whatever
you'll give me.

i guess there is no perfect answer.

cheers.

-a

···

On Thu, 22 Sep 2005, Damphyr wrote:

Well I assume you do that for yourself locally. What do you do when
distributing something that uses alib? When having application A and
application B use alib do you distribute one copy of the alib files with
each app or do you require someone to install alib? I am reluctant to
require installation of a "private" library be it tar or gem. I prefer using
a rakefile to grab the appropriate files and bundle them together with the
app (which adds a reusable rake task definition to the lib :slight_smile: ). So my box
has the library installed complete with versioning and the app gets a copy
to be used from '.'. One major drawback of this approach is when drastic
changes in the "private" library break the applications - releasing bugfixes
for the app requires updating to the current version of the lib. You use
versioning in the library, for the moment I use my source control system to
keep the versions aligned. I guess what I am formulating is the desire to
handle my snippets like a separate project internally, but distribute them
as integral pieces of each application.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

Keep your library as a separate project. In your other projects have a
Rakefile task to copy the lib over prior to distribution. Use Austin's
conditional require suggestion.

Also, if your snippets are general purposed enough one option is to
submit them for inclusion in Nano/Mega, or similar project.

T.