Dividing a gem into 2 or 3 gems

Ruby
1

I have a gem that has been growing for a while (e.g. mygem). There’s a
lot of experimental stuff being added. So I’d like to have a mygem-core
which has the basic stuff that should be stable and fairly frozen. Then
i can quickly respond with a fix, rather than wait for the other changes
to stabilize.

The other stuff can go into mygem-extra or mygem-utils and
mygem-experimental. Some of it may move from “experimental” to “util” or
“extra”
as the API stabilizes.

I am not clear what the best way is. Do i keep the original gem name and
make it implicitly the “core” removing all other stuff from it. Or
should i create new gems for these 3 or 4, meaning that the original gem
(name) will no longer exist.

Should i keep it in one git repo within the same directory structure
(meaning multiple gemspec files). Or divide/clone it into separate
github repos. However, I am hoping that even across these gems the root
directory will still be mygem.

Will dividing the gem lead to other problems ?

2

Have you got this under version control? If so, have you considered
just using branches? I’m going to use git terminology here, and assume
your question is about how the gem is developed.

You can have master contain your stable, tested code, and an
experimental branch onto which you commit your experimental features,
before merging it back into master. Or you can simply have individual
feature branches off master which merge in when they’re ready.

Or, as a combination of the two, you can have an experimental branch
off master, with feature branches off experimental (not master).
Feature branches merge into experimental, stabilise, then go into
master.

3

I do not having working knowledge to give advice from. However, It may
be helpful to look at the following gems: rspec and refinerycms.

Those are just two off the top of my head which are set up as multiple
gems.

HTH

4

Check out how the activerecord-jdbc-adapters work:

5

Adam P. wrote in post #1031235:

Have you got this under version control? If so, have you considered
just using branches? I’m going to use git terminology here, and assume
your question is about how the gem is developed.

Yes, its in github and I do use branches for experiments. Each version
is saved as a branch after release. That’s not the issue. The issue was
with size. and the fact that I felt it would be better splitting it into
multiple gems. Put the basic infrastructural code into a “core” gem.

Put higher abstractions into a separate one. Try to keep core as minimal
and backward compatible so people upgrading don’t find apps breaking.
The higher abstractions can have more volatility.

I am also asking whether multiple (separate) gems can be created using
one github repo, or should they have a separate repo each.

6

If you are creating separate packages then create separate repos. If
your a
very hesitant to do so, then you probably don’t really need separate
packages. Remember (in real Ruby projects) you do not have to load every
script just b/c it’s there in lib/. Some files can be loaded optionally.

require ‘mygem’
require ‘mygem/experimental’

T.

7

Lake D. wrote in post #1031242:

Those are just two off the top of my head which are set up as multiple
gems.

Resolve Digital · GitHub
RSpec · GitHub

HTH

Yes, the rspec (and jdbc link provided by Steve) show 2 different ways
of doing it. rspec has separate repos for core mock expectations. They
all use lib/rspec as their dir structure. There’s also an rspec repo and
the gem depends on the others, so installing it, automatically installs
the others so you get the complete project. This sounds like what i have
in mind.

jdbc uses one repo, each adapter has its own directory, and within it,
its own lib, gemspec etc.

Both require moving files around quite a bit. In the second case, its
within a repo so seems easy (git mv). In the second case, its across
repos. Wondering how to do that. Clone ? or Just copy files and delete ?

The second case is still not clear in my mind. jdbc uses one repo, so
there’s only one master branch. When the user branches, the entire
structure gets branched. All adapters ??? Surely I understand it wrong.

8

-----Messaggio originale-----
Da: Eric H. [mailto:[email protected]]
Inviato: venerd 11 novembre 2011 01:56
A: ruby-talk ML
Oggetto: Re: Dividing a gem into 2 or 3 gems

On Nov 10, 2011, at 1:31 AM, Rahul K. wrote:

I have a gem that has been growing for a while (e.g. mygem). There’s a
lot of experimental stuff being added. So I’d like to have a
mygem-core which has the basic stuff that should be stable and fairly
frozen. Then i can quickly respond with a fix, rather than wait for
the other changes to stabilize.

I prefer to:

  1. Keep the original gem name
  2. Make a plugin system and move the fast-moving parts into plugins.
    The
    core gem should automatically load plugin gems.

The other stuff can go into mygem-extra or mygem-utils and
mygem-experimental. Some of it may move from “experimental” to “util”
or “extra” as the API stabilizes.

Give each experiment a reasonable name and release them as separate
gems,
especially if you’re not interested in maintaining or exploring them
forever. This allows you to hand them off to more-interested
maintainers or
abandon them without breaking API.

I am not clear what the best way is. Do i keep the original gem name
and make it implicitly the “core” removing all other stuff from it. Or
should i create new gems for these 3 or 4, meaning that the original
gem
(name) will no longer exist.

Should i keep it in one git repo within the same directory structure
(meaning multiple gemspec files). Or divide/clone it into separate
github repos. However, I am hoping that even across these gems the
root directory will still be my gem.

Use separate repositories for separate gems. You can create an
organization
for your repositories on github.

Will dividing the gem lead to other problems ?

Splitting up a gem won’t lead to other problems by itself.

To save yourself a possible hassle, avoid having = dependencies between
the
pieces. An = dependency forces you to release at least two gems at once
if
you want both pieces to be using the latest code. Instead use ~> to
specify
a version range that is acceptable.

Use a good tool like Hoe to manage the releases of your many gems. A
good
tool makes releasing easy, so an update that affects three of your gems
will
not be tedious and should take only a few minutes, not an hour or more.

–
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Capodanno a Riccione, Pacchetto Relax: Mezza Pensione + bagno turco +
solarium + massaggio. Wifi e parcheggio gratis. 2 giorni euro 199 a
persona
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid979&d)-12

9

On Nov 10, 2011, at 1:31 AM, Rahul K. wrote:

I have a gem that has been growing for a while (e.g. mygem). There’s a
lot of experimental stuff being added. So I’d like to have a mygem-core
which has the basic stuff that should be stable and fairly frozen. Then
i can quickly respond with a fix, rather than wait for the other changes
to stabilize.

I prefer to:

  1. Keep the original gem name
  2. Make a plugin system and move the fast-moving parts into plugins.
    The core gem should automatically load plugin gems.

The other stuff can go into mygem-extra or mygem-utils and
mygem-experimental. Some of it may move from “experimental” to “util” or
“extra” as the API stabilizes.

Give each experiment a reasonable name and release them as separate
gems, especially if you’re not interested in maintaining or exploring
them forever. This allows you to hand them off to more-interested
maintainers or abandon them without breaking API.

I am not clear what the best way is. Do i keep the original gem name and
make it implicitly the “core” removing all other stuff from it. Or
should i create new gems for these 3 or 4, meaning that the original gem
(name) will no longer exist.

Should i keep it in one git repo within the same directory structure
(meaning multiple gemspec files). Or divide/clone it into separate
github repos. However, I am hoping that even across these gems the root
directory will still be my gem.

Use separate repositories for separate gems. You can create an
organization for your repositories on github.

Will dividing the gem lead to other problems ?

Splitting up a gem won’t lead to other problems by itself.

To save yourself a possible hassle, avoid having = dependencies between
the pieces. An = dependency forces you to release at least two gems at
once if you want both pieces to be using the latest code. Instead use
~> to specify a version range that is acceptable.

Use a good tool like Hoe to manage the releases of your many gems. A
good tool makes releasing easy, so an update that affects three of your
gems will not be tedious and should take only a few minutes, not an hour
or more.

10

-----Messaggio originale-----
Da: Luca (Email) [mailto:[email protected]]
Inviato: gioved 29 dicembre 2011 07:58
A: ruby-talk ML
Oggetto: I: Dividing a gem into 2 or 3 gems

–
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Conto Arancio al 4,20%. Zero spese e massima liberta’, aprilo in due
minuti!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid919&d)-12