Extract EncodedString helper into its own gem for greater good?

[bf4]

ref: mikel/mail#921

I think people could really make use of this.

I'd be happy to do the work, just would need advice on gem name and org to use.

• https://github.com/rspec/rspec-support/blob/81e33d4ed3/lib/rspec/support/encoded_string.rb
• https://github.com/rspec/rspec-support/blob/81e33d4ed3/spec/rspec/support/encoded_string_spec.rb
• https://github.com/rspec/rspec-support/blob/81e33d4ed3/lib/rspec/support/spec/string_matcher.rb

[myronmarston]

An extracted gem could certainly be beneficial to the community. However, I don't think we'd be able to use it. We have a general "don't use external gems" rule -- not because we don't trust them or anything like that, but because if we depend upon version 2.x of a particular gem and in a user's project they use another gem that depends on version 1.x or 3.x then they can't use RSpec to test their application. We place a high value on RSpec being usable in any ruby project, regardless of their other dependencies so it's not really an option for us to start depending on more gems.

[bf4]

I was thinking it could be rspec-support-encoded_string, but was unsure about it. Thanks for the quick response!

[myronmarston]

Woops. Hit the wrong button.

I was going to say that if it's a gem owned by us with rspec in the name we can depend on it, but I have a hard time seeing other projects depending upon a specific rspec gem like that (unless they are themselves an RSpec extension...). Plus I'm not sure we want to take on the responsibility of maintaining an encoding API for the community.

[JonRowe]

It could be rspec/encoded_string that way it's still owned by us but could be considered usable by other projects. But other peoples aims may be different to ours...

[myronmarston]

It could be rspec/encoded_string that way it's still owned by us but could be considered usable by other projects. But other peoples aims may be different to ours...

But if other projects start using it and depend on a certain version, we're back to the situation where users may not be able to run a current version of RSpec due to it needing a certain version of rspec/encoded_string while another library they depend upon needs a different version.

[JonRowe]

Yeah, @bf4 if you'd like to extract our code into a gem you're welcome to, MIT license and all :) but I think @myronmarston's right that it's too much of a headache for us to use it ourselves

[JonRowe]

Although @myronmarston we could publish another gem from this repo keeping the code vendored for our use but published separately for others... Does still seem like effort...

[bf4]

I think I'll mirror it like psych and stdlib ie contribute back

B mobile phone

On Oct 21, 2015, at 6:25 PM, Jon Rowe notifications@github.com wrote:

Although @myronmarston we could publish another gem from this repo keeping the code vendored for our use but published separately for others... Does still seem like effort...

—
Reply to this email directly or view it on GitHub.

[myronmarston]

Sounds good!

Sent from my iPhone

On Oct 21, 2015, at 6:50 PM, Benjamin Fleischer notifications@github.com wrote:

I think I'll mirror it like psych and stdlib ie contribute back

B mobile phone

On Oct 21, 2015, at 6:25 PM, Jon Rowe notifications@github.com wrote:

Although @myronmarston we could publish another gem from this repo keeping the code vendored for our use but published separately for others... Does still seem like effort...

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[bf4]

Basic extraction done., now at https://github.com/bf4/encoded_string