search

cvonkleist / encrypted_cookie

AES-128 encrypted session cookies for Rack (and Sinatra and other frameworks).
MIT License
53 stars 14 forks source link

Add Gemfile, have gemspec specify runtime/development dependencies. #5

Closed danp closed 10 years ago

danp commented 11 years ago

This helps someone who wants to hack on encrypted_cookie get started quicker by having all dependencies codified and installable with bundle install.

Along the way I specified a runtime dependency on the gem for rack >=1.0 and changed use of should_not raise_error in a spec to silence an rspec deprecation warning.

I regenerated the gemspec using bundle exec rake build_gemspec to add the necessary dependency information. I think things are pretty much the same, I changed the date attribute back to what it was. The signing info was lost, though, but after looking at echoe a little I think the gem could still be signed using the previous paths by running something like:

$ GEM_PRIVATE_KEY=/home/cvk/.gemcert/gem-private_key.pem \
    GEM_CERTIFICATE_CHAIN=/home/cvk/.gemcert/gem-public_cert.pem \
    bundle exec rake package

Might be worth considering dropping use of echoe at some point, looks like it's no longer maintained.

namelessjon commented 11 years ago

I'd probably make it depend on rack ~> 1.1 (>= 1.1.0, < 2.0.0). Rack 2.0 could change how middleware works (to, e.g. support streaming or make websockets easier or whatever). Also, rack 1.0 doesn't have secure_compare.

danp commented 11 years ago

Good call, updated. I had checked inclusion of secure_compare but perhaps got confused after I discovered the gemspec was auto-generated and ported dependencies to the echoe stuff in Rakefile.

Any thoughts on pinning for the development dependencies? I suppose since they are for development there's not as much need for concern about incompatibilities during use. Probably whatever's current for each would be good.

mkristian commented 11 years ago

in my experience (might be limited) I use always those semantic version ranges !! when switching from rspec ~>2.14 to rspec 3 will come with API changes I guess. kind of I try to make sure a clean checkout just works - now in some not too distant future.

well just that is my way of dealing with the version problems ;)

danp commented 11 years ago

Just added another change to pin development dependencies to keep them close to what I have things working locally with.

mkristian commented 11 years ago

great ;)

cvonkleist commented 10 years ago

Hey, @dpiddy. I'm overloaded with other projects, and it's taking me forever to follow up on PRs. Making you a collaborator so you can accomplish this. Thanks!

danp commented 10 years ago

Thanks! Going to merge this and get back to #4.