Sqs active job as own gem #144
Conversation
|
Tests are working yet, the dummy environment needs to be unwound from other dependencies. |
|
Thanks. I'll get back to you in this. We will want to think about gem naming and plan out work to move features out of the rails gem. |
|
Sounds good. I'll do some real world of testing of this meanwhile. |
|
Thanks. It may be a bit before I get to this. I am thinking maybe it shouldn't live in this GitHub if it's not exclusively for rails. We have a gem called aws-sessionstore-dynamodb that works for rack applications, and then we have a rails layer for it. I am thinking we would want an aws-activejob-sqs gem and repository. I am thinking whether or not Rails loading checks should be done in both cases, removed from aws-sdk-rails. E.g. If Rails was loaded, then insert a railtie or look for config. |
|
@mullermp A completely seperate gem does seem like a decent and logical way to go. However, ActiveJob is part of the Rails project so keeping AWS support for ActiveJob close to Rails support could make sense as well. I agree that the conditional Rails loading checks aren't great. There's only 2 of them and I suspect there may be a way to remove them. |
| @@ -32,5 +32,7 @@ Gem::Specification.new do |spec| | |||
| spec.add_dependency('concurrent-ruby', '~> 1.3', '>= 1.3.1') # Utilities for concurrent processing | |||
| spec.add_dependency('railties', '>= 7.0.0') # Minimum supported Rails version | |||
|
|
|||
| spec.add_dependency('sqs-active-job', version) | |||
There was a problem hiding this comment.
I think we potentially would want this to be an open ended dependency
There was a problem hiding this comment.
Does spec.executables = ['aws_sqs_active_job'] still work with the gem split out?
There was a problem hiding this comment.
I think we can also remove sqs and concurrent-ruby from the dependencies here.
| @@ -15,6 +16,8 @@ module Rails | |||
| # | |||
| # SQS-based queuing backend for Active Job. | |||
| module SqsActiveJob | |||
| VERSION = File.read(File.expand_path('../../VERSION', __dir__)).strip | |||
There was a problem hiding this comment.
I think we'd probably want to start versioning this separately
| end | ||
|
|
||
| def run | ||
| # exit 0 | ||
| boot_rails |
There was a problem hiding this comment.
I'm not sure the best way to do this, but what about trying to require rails and running boot_rails only when its available? something like:
begin
require 'rails'
boot_rails
rescue LoadError
# no boot
end
There was a problem hiding this comment.
Thanks for reviewing.
I moved the Rails booting to the executable which I think is a better place for it. The poller doesn't need to control what environment it's polling in. If you really want the poller to do booting we could split the poll method to boot and then call poll_without_booting_rails. This new method poll_without_booting_rails could then be used by non-rails environments that want to do polling. Other environments can easily create their own executables if desired.
|
Work has been moved to aws/aws-activejob-sqs-ruby#1 |
Issue #, 142
Description of changes:
Moved sqs-active-job to a top level directory and created it's own gemspec.
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license.