I'm developing a gem with an idea to replace an existing gem which I don't
control. The replacement gem provides a compatible API.
For my own project, of course I can just switch the gem i the Gemfile. But,
what about other gems which depend on the original gem that I want to
replace?
Is it possible to say - this gem dependency will now be provided by some
other gem? Is there some way to tell Rubygems/Bundler to ignore a specific
dependency?
This would be similar to say, how arch linux packages work, where there are
several packages that, for example, provide the java runtime environment,
and you can choose which one you want to use.
Could your gem reimplement the require method to look for the gems you want
to replace and then load your indicated replacement gem instead?
···
On Sun, Oct 9, 2016, 3:06 AM Matthew Kerwin <matthew@kerwin.net.au> wrote:
On 9 October 2016 at 19:02, Samuel Williams < > space.ship.traveller@gmail.com> wrote:
I'm developing a gem with an idea to replace an existing gem which I don't
control. The replacement gem provides a compatible API.
For my own project, of course I can just switch the gem i the Gemfile.
But, what about other gems which depend on the original gem that I want to
replace?
Is it possible to say - this gem dependency will now be provided by some
other gem? Is there some way to tell Rubygems/Bundler to ignore a specific
dependency?
This would be similar to say, how arch linux packages work, where there
are several packages that, for example, provide the java runtime
environment, and you can choose which one you want to use.
Thanks for any ideas.
Give your gem a different name (depending on the situation it could be
alright to base the name on the old gem's name, especially if the old one
seems to be abandoned, just be careful of things like what is called
"passing off" in the UK), write it really well, make your one an obvious
and apparent improvement, promote it, and let market forces do the rest.
Give your gem a different name (depending on the situation it could be
alright to base the name on the old gem's name, especially if the old one
seems to be abandoned, just be careful of things like what is called
"passing off" in the UK), write it really well, make your one an obvious
and apparent improvement, promote it, and let market forces do the rest.
Cheers
···
On 9 October 2016 at 19:02, Samuel Williams <space.ship.traveller@gmail.com> wrote:
I'm developing a gem with an idea to replace an existing gem which I don't
control. The replacement gem provides a compatible API.
For my own project, of course I can just switch the gem i the Gemfile.
But, what about other gems which depend on the original gem that I want to
replace?
Is it possible to say - this gem dependency will now be provided by some
other gem? Is there some way to tell Rubygems/Bundler to ignore a specific
dependency?
This would be similar to say, how arch linux packages work, where there
are several packages that, for example, provide the java runtime
environment, and you can choose which one you want to use.
Matthew, the problem is I want to do this in my own project. I want to use
my own gem to replace an existing gem, which is a dependency of gems in my
existing Gemfile.
···
On 10 October 2016 at 08:19, Raj Sahae <rajsahae@gmail.com> wrote:
Could your gem reimplement the require method to look for the gems you
want to replace and then load your indicated replacement gem instead?
On Sun, Oct 9, 2016, 3:06 AM Matthew Kerwin <matthew@kerwin.net.au> wrote:
On 9 October 2016 at 19:02, Samuel Williams <space.ship.traveller@gmail. >> > wrote:
I'm developing a gem with an idea to replace an existing gem which I
don't control. The replacement gem provides a compatible API.
For my own project, of course I can just switch the gem i the Gemfile.
But, what about other gems which depend on the original gem that I want to
replace?
Is it possible to say - this gem dependency will now be provided by some
other gem? Is there some way to tell Rubygems/Bundler to ignore a specific
dependency?
This would be similar to say, how arch linux packages work, where there
are several packages that, for example, provide the java runtime
environment, and you can choose which one you want to use.
Thanks for any ideas.
Give your gem a different name (depending on the situation it could be
alright to base the name on the old gem's name, especially if the old one
seems to be abandoned, just be careful of things like what is called
"passing off" in the UK), write it really well, make your one an obvious
and apparent improvement, promote it, and let market forces do the rest.
Raj, that seems awfully complicated given that what I really want is
something like:
gem "foo", provided_by: "my_foo"
···
On 11 October 2016 at 10:11, Samuel Williams <space.ship.traveller@gmail.com > wrote:
Matthew, the problem is I want to do this in my own project. I want to use
my own gem to replace an existing gem, which is a dependency of gems in my
existing Gemfile.
On 10 October 2016 at 08:19, Raj Sahae <rajsahae@gmail.com> wrote:
Could your gem reimplement the require method to look for the gems you
want to replace and then load your indicated replacement gem instead?
On Sun, Oct 9, 2016, 3:06 AM Matthew Kerwin <matthew@kerwin.net.au> >> wrote:
On 9 October 2016 at 19:02, Samuel Williams < >>> space.ship.traveller@gmail.com> wrote:
I'm developing a gem with an idea to replace an existing gem which I
don't control. The replacement gem provides a compatible API.
For my own project, of course I can just switch the gem i the Gemfile.
But, what about other gems which depend on the original gem that I want to
replace?
Is it possible to say - this gem dependency will now be provided by some
other gem? Is there some way to tell Rubygems/Bundler to ignore a specific
dependency?
This would be similar to say, how arch linux packages work, where there
are several packages that, for example, provide the java runtime
environment, and you can choose which one you want to use.
Thanks for any ideas.
Give your gem a different name (depending on the situation it could be
alright to base the name on the old gem's name, especially if the old one
seems to be abandoned, just be careful of things like what is called
"passing off" in the UK), write it really well, make your one an obvious
and apparent improvement, promote it, and let market forces do the rest.
Just declare that earlier than the gems which depend on 'foo'
-Rob
···
On 2016-Oct-10, at 17:12 , Samuel Williams <space.ship.traveller@gmail.com> wrote:
On 11 October 2016 at 10:11, Samuel Williams <space.ship.traveller@gmail.com <mailto:space.ship.traveller@gmail.com>> wrote:
Matthew, the problem is I want to do this in my own project. I want to use my own gem to replace an existing gem, which is a dependency of gems in my existing Gemfile.
On 10 October 2016 at 08:19, Raj Sahae <rajsahae@gmail.com <mailto:rajsahae@gmail.com>> wrote:
Could your gem reimplement the require method to look for the gems you want to replace and then load your indicated replacement gem instead?
On Sun, Oct 9, 2016, 3:06 AM Matthew Kerwin <matthew@kerwin.net.au <mailto:matthew@kerwin.net.au>> wrote:
On 9 October 2016 at 19:02, Samuel Williams <space.ship.traveller@gmail.com <mailto:space.ship.traveller@gmail.com>> wrote:
I'm developing a gem with an idea to replace an existing gem which I don't control. The replacement gem provides a compatible API.
For my own project, of course I can just switch the gem i the Gemfile. But, what about other gems which depend on the original gem that I want to replace?
Is it possible to say - this gem dependency will now be provided by some other gem? Is there some way to tell Rubygems/Bundler to ignore a specific dependency?
This would be similar to say, how arch linux packages work, where there are several packages that, for example, provide the java runtime environment, and you can choose which one you want to use.
Thanks for any ideas.
Give your gem a different name (depending on the situation it could be alright to base the name on the old gem's name, especially if the old one seems to be abandoned, just be careful of things like what is called "passing off" in the UK), write it really well, make your one an obvious and apparent improvement, promote it, and let market forces do the rest.