Use Versionaire instead

[bkuhlmann]

Hello. 👋 This isn't really an issue in the truest sense but wasn't sure where to log this information so opted to create an issue on this project instead. I was surprised to see this gem show up and had only stumbled across it because I had been doing some OAuth work as of late.

Anyway, I'm the maintainer of the Vesionaire gem -- which is actively maintained -- where I had solved this issue back in 2016. I've written and spoken about versioning within Ruby for many years and use Versionaire in all of my projects.

The main qualm I have this with the design of this gem and my gem is that while we are both adding version support to Ruby but this project is not providing a primitive type. In essence a whole value object that is immutable but easily comparable. With structs you now have proper encapsulation of version data which provides a richer experience. It looks like there are performance concerns (although, I've not checked) since the design of this gem constantly requires one to obtain major, minor, patch level information by constantly converting to an array and then using magic numbers to pluck out which segment of the version you want to use. This operation is done repeatedly throughout this design.

Anyway, I'm not sure what actions are to be taken here. Mostly wanted to pop up and express concerns with this design and how it conflicts with an established gem. If anything, I'd think you'd want to point people to the Versionaire gem since it provides a much more robust Object API. 😅

[pboling]

Hi @bkuhlmann !

First, the good. I agree with everything you said. 😄

This was merely an extraction of the existing very simple code that has long been in the oauth2 gem. I think little thought was given to performance.

I absolutely will be pointing people to versionaire going forward, when the use case warrants it. I'll update the README to point people in that direction.

I did an extensive search of the landscape of "versioning" gems before writing this one. I had no desire to throw another log on the fire unless it was required.

So, the bad news is, I still think it is required, at least in the case of the oauth2 gem. We just dropped support for Ruby 1 (yes, ONE). We are now sitting pretty with support back to Ruby 2.2, and we'll be stuck there for a few minutes. The oauth2 gem is used by many thousands of projects (including Github!) and there is a wide variety of legacy apps and tools that may not have resources to upgrade Ruby.

Your gem, while awesome, starts supporting a minimum of Ruby 2.3 even going back all the way to release 1.0, with current release being at ~> 3.1 so it is a non-starter for using inside oauth2.

I have begun adding version_gem to all my gems (yes, this is still the bad news section 🤣 ) and the performance concerns are only mitigated by the feature being new everywhere I add it, so no one is using it, and if they start, hopefully they will test it first! I think version introspection can help us build better libraries.

So I need to figure out how to do a better job of the version introspection, and probably should do like your gem does...

Now for the really bad part...

The solution has to support the VERSION constant of the library being loaded from the gemspec, and that's before (or during) bundler. This means it can't need to be present. This is why:

• the actual VERSION is just a string, and the methods parse it
• the version.rb file doesn't require, reference, or use any other library, and it can't. The version_gem introspection is layered onto the Version module when the gem loads, long after gemspec parsing is over.

Hopefully we can figure out a way to merge most/all of your approach with an approach that A) supports OLD ruby, and B) falls back to a standard Ruby String so the Gemspec is satisfied.

Lastly, I had never, until now, come across alchemists, and I love what you are doing there. I'll be signing up.

[pboling]

@bkuhlmann As an aside, what is the reasoning behind building PKCE with no connection to the oauth2 gem? License considerations?

[bkuhlmann]

This was merely an extraction of the existing very simple code that has long been in the oauth2 gem. I think little thought was given to performance.

Actually, now that you mention it, I do recall seeing this embeded within the OAuth gem when I was source diving a while back. Thanks, this makes more sense now.

I absolutely will be pointing people to versionaire going forward, when the use case warrants it. I'll update the README to point people in that direction.

Thanks!

I did an extensive search of the landscape of "versioning" gems before writing this one. I had no desire to throw another log on the fire unless it was required.

Yeah, I'd like to see this landscape narrow rather than expand as well. 😅

So, the bad news is, I still think it is required, at least in the case of the oauth2 gem.

OK, that's a valid point and was wondering if that was the case. I wasn't aware you supported all the way back to Ruby 1.x.x. Wow.

Your gem, while awesome, starts supporting a minimum of Ruby 2.3 even going back all the way to release 1.0, with current release being at ~> 3.1 so it is a non-starter for using inside oauth2.

Fair. I generally don't support older versions myself since -- as an open source maintainer -- I very seldom get funding for any of my work so generally focus on staying current with Ruby. Totally understand that some projects can't or might not even be able to do that.

hopefully they will test it first!

Ha, being a consultant, I like to think optimistically like this too but in reality, many don't test (or test well). I guess I'll always have a job, though. 😅

The solution has to support the VERSION constant of the library being loaded from the gemspec, and that's before (or during) bundler. This means it can't need to be present.

OK, I was wondering about that although not sure I completely follow this use case? I'm assuming there is some sticky legacy situation in which the version information must be delayed in loading or it'll cause a conflict with this gem being installed/used?

I had never, until now, come across alchemists, and I love what you are doing there. I'll be signing up.

Thanks. 😅 Yeah, people keep telling me to advertise more but I'm still in grass roots mode. I suppose I'll have to get more used to marketing myself more in the future.

As an aside, what is the reasoning behind building PKCE with no connection to the oauth2 gem? License considerations?

Yeah, good question. A couple reasons for the decision but not due to licensing:

• A while back, I was working for a client that wanted to integrate Okta into their architecture but -- as you may or may not know -- Okta doesn't have native Ruby support (even though they bought Auth0 a while back). I needed to build a Ruby API client that wrapped Okta's API. During the course of that work I needed PKCE support too but reaching for OAuth2 gem was too heavy of a lift since all I needed was a good PKCE implementation.
• So much of my architecture and design used Dry RB so the PKCE gem was build on top of monads using the Railway Pattern which means I could avoid throwing exceptions all over the place.

That's the primary reason. I ended up opening sourcing the solution in hopes it might be of help to others that needed small but simple gems for their needs. I debated whether the community would like or care about this gem but eventually thought it could be of help to some specific use cases, like mine. I could take it down if you think it conflicts or distracts from the work you are doing in this space.

[pboling]

I could take it down if you think it conflicts or distracts from the work you are doing in this space.

No need to take it down. I have intended to move more of my work in the direction of the dry tools, but haven't been able to focus long enough to really dig into them beyond deciding it was generally a "better way".

not sure I completely follow this use case?

Basically when you load a version.rb file from the gemspec that file can't depend on anything more than standard Ruby libs. It can't load a gem, or need a gem, because you are at that point outside bundler. If we want to keep the version defined in only a single place, and refer to that constant everywhere we need it, then we can't use a gem to define it.

If we use a gem to enhance it later then that's fine. And maybe I could do that with versionaire, but most of the tools I support are highly legacy. I have multiple gems that still support ruby 1.8 (because they are RSpec plugins, and RSpec still supports ruby 1.8).

[bkuhlmann]

Yeah, there are good and bad parts to the Dry RB ecosystem but, for the most part, it's an elegant blending of Object Oriented and Functional Programming principals. 🎉

Ah, I see what you are saying now regarding gem version information. I've got a solution for this but, unfortunately, it requires a modern version of Ruby to use and might still not address your primary needs. Regardless, here's a quick summary in case it's of interest/help:

• Spek - This is the gem I built to make obtaining version information with enhanced gem specification details in general. It's meant to consume your *.gemspec file so you can define your version information there without any need for a separate file.
• Gemsmith - This is another gem of mine for building professional gems. The reason I call attention to it is not because of the gem building capabilities -- allthough you can use it to build a demo gem for experimentation purposes based on what I'm documentint here -- but because of the lazy loading of gem specification information. This line in particular shows how I lazy load version information. This is made possible through the use of Dry Container.

Anyway, maybe the above might be of some help or at least provide an alternate way to tackle and solve this problem.

[pboling]

Moved to GitLab!