Gemspec version about spree_auth_devise

[jsqu99]

+1

[radar]

Truth be told, I've not been paying attention to the version number in the gemspec. I've been advising people to install this gem from GitHub so that we can push out releases easily. As such, I would suggest to ignore rubygems.org versions of the spree_auth_devise gem.

[jsqu99]

Thanks for the reply Ryan.

I believe the problem we end up having is when we have a spree extension that relies on a Spree::User.

We had been putting spree_auth_devise in the gemspec (but now that I think about it, that's probably a horrible idea as it ties the user to a specific spree auth implementation).

@mscottford could we have gotten around this by using class evaling Spree.user_class instead of Spree::User ?

[radar]

I think Spree.user_class would be better to class eval, as any Spree specific stuff is added to this class automatically by the user_class_extensions file.

On Mon, Apr 22, 2013 at 9:17 PM, Jeff Squires [email protected]
wrote:

Thanks for the reply Ryan.
I believe the problem we end up having is when we have a spree extension that relies on a Spree::User.
We had been putting spree_auth_devise in the gemspec (but now that I think about it, that's probably a horrible idea as it ties the user to a specific spree auth implementation).

@mscottford could we have gotten around this by using class evaling Spree.user_class instead of Spree::User ?

Reply to this email directly or view it on GitHub:
#53 (comment)

[mscottford]

I forgot to chime in on this a while ago... if someone's writing a gem that depends on spree_auth_devise, which is how we ran into this problem, then this issue also makes it hard to push that gem to rubygems. I understand that telling people that are using spree_auth_devise in their apps to just point to Github in the Gemfile, but what's the correct approach for an extension or other gem?

[radar]

The extension or another gem should recommend to point to GitHub in the README.