Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Jonah
@jonahx
@timriley yep that’s exactly how it should work. i was trying to work around it not working like that, which i just assumed… should have known better.
Jonah
@jonahx
I notice in the below that setting up an auto-register dir is a separate step from updating the $LOAD_PATH with load_path!. In what circumstance would you do the auto-register step without also updating the load path?
class Application < Dry::System::Container
  configure do |config|
    config.root = Pathname('./my/app')

    # we set 'lib' relative to `root` as a path which contains class definitions
    # that can be auto-registered
    config.auto_register = 'lib'
  end

  # this alters $LOAD_PATH hence the `!`
  load_paths!('lib')
end
Piotr Solnica
@solnic
@jonahx when lib is already in your load path
Taskhyn Maksim
@sarbazx
Hi all, is there any good tutorial for web development using dry-rb gems?
Gustavo Caso
@GustavoCaso
@sarbazx This guide is pretty complete http://dry-web-roda-todo-app.readthedocs.io/en/0.9.1/
Is written by @alejandrobabio
Taskhyn Maksim
@sarbazx
@GustavoCaso thanks!
Gustavo Caso
@GustavoCaso
Thanks @alejandrobabio helping with this release :clap:
Alejandro E. Babio
@alejandrobabio
No trouble at all
Jonah
@jonahx
separate question: say you use a few custom string utility functions that are defined on a module, and some class uses the. typical solution is to require ‘my_string_utils’ and then either include it within the class that uses it; or hardcode stuff like StringUtils.method into the classes methods; or pass StringUtils into the class’s constructor, and then use it as needed without a hardcoded dependency. The auto_injector could clearly be used to implement the final solution, which is typically the best one anyway. what about having the container register the individual functions, so that you could include them with exactly the granularity you need? thoughts on the wisdom of this? is there any builtin support for doing this as a bulk registration, or would you have to manually register each of the functions if you wanted to do something like this?
Piotr Rybarczyk
@Argonus
Hi, Do you have versioning of documentation? That would be awesome :)
Gustavo Caso
@GustavoCaso
Not yet @Argonus. Is something we need to tackle, I completly agree with you it would be awesome
Scott Treppa
@streppa
Hey guys. Having some trouble figuring out what happened between v0.4.4 and 0.4.5 of 'dry-auto_inject'. i might be doing something that isn't supposed to be done but I'm not sure. I've created a contrived example.
At the bottom of the script is how I want to interact with my lib. I had to juggle some things to get it working how I wanted.
But transitioning from dry-auto_inject 0.4.4 to 0.4.5+ results in an argument error. I'm pretty sure it on the 'super' call in MadLib#intialize.
'super' has to be called to get the injection to work.
Scott Treppa
@streppa
My actual implementation is for a ruby json api wrapper. I'd like to be able to set some values wrapper wide but with the ability to instantiate a new client with new parameters if necessary.
So... set host and api version in the configuration step but authentication credentials and other options might be different from client instantiation to instantiation.
Spencer Goh
@dymaxionuk

dry-transaction and wondering how one might facilitate long running tasks: eg.

step :preprocess_params
enqueue :generate_report # long running, handled by exector/threadpool or sidekiq
step :extract_and_parse_report_output
step :persist_to_storage
step :email_user_notification
  • I don't think there's a mechanism for callback and resumption of a next step.
  • some async/await fiber like dispatch and resumption of execution path would suit
  • in lieu of this, I'll have to
    • Split the transaction into 2 parts (before and after the async/long task)
    • have my long running task, on completion, callback/publish an event/message, then start TransactionPart2.call(result)

I like the idea that the transaction encapsulates and clearly declares the end to end steps, but I can't think of a clean way to handle the async or long running task.
I could wrap the whole transaction call in a thread/threadpool....

what's the best practice around this?

Nikita Shilnikov
@flash-gordon
dry-transaction works with Result/Either which is a synchronous computation. If you wrap it with a thread pool you should be fine. There is also Task in dry-monads 1.0,0.beta1+ that can be run on a thread pool
Tim Riley
@timriley
@dymaxionuk what you’ve done so far is the best one can do for the moment. I was actually thinking about this problem just a couple of weeks ago - I’d like to add support for re-entering/resuming a transaction mid-way so your initial plan becomes possible
I have transactions that suffer from exactly the same problem - an “enqueue” step forces me to split them into two
Jonah
@jonahx

In the dry-system docs it says:

When components are auto-registered, default identifiers are created based on file paths, ie lib/api/client resolves to API::Client class with identifier api.client.

How is API determined to be all caps here? I would think it would be Api...

Or is it assuming that the Client class defined my the file lib/api/client is inside a module called API?
Gustavo Caso
@GustavoCaso
it should be inside a module
or a class @jonahx
Gustavo Caso
@GustavoCaso
you can look at the test suite inside the library to see some examples
Hope this helps
Jonah
@jonahx
@GustavoCaso thanks
Jonah
@jonahx

I’m having trouble getting dry-system to work, and I think I’m missing something obvious, but even after reading the docs and test cases I don’t know what it is. In system/container.rb I have:

require 'dry/system/container'

class Application < Dry::System::Container
  configure do |config|
    config.root = Pathname('.')
    config.auto_register = 'domain'
    config.auto_register = 'use_cases'
  end

  load_paths!('lib', 'use_cases')
end

Application.finalize!

p Application['bot_reply']

and in system.import.rb I have:

require 'system/container'
Import = Application.injector

In lib/bot_reply.rb I have:

require 'dry-struct'
require 'import'

class BotReply < Dry::Struct
# stuff
end

If I execute system/container.rb as a test, I get the error:

Nothing registered with the key "bot_reply" (Dry::Container::Error)

What am I missing?

Tim Riley
@timriley
    config.auto_register = 'domain'
    config.auto_register = 'use_cases'
Those aren’t right if you’re expecting lib/bot_reply.rb to be registered
And you should only have one auto_register config (it can be an array)
try this:
config.auto_register = “lib”
then, after you’ve finalized your container, you can do Application.keys to see what it has
Jonah
@jonahx
@timriley I’m still getting empty keys after making those changes and fixing the typo you caught (lib should have been domain):
require 'dry/system/container'

class Application < Dry::System::Container
  configure do |config|
    config.root = Pathname('.')
    config.auto_register = 'domain'
    # config.auto_register = 'use_cases'
  end

  load_paths!('domain')
end

Application.finalize!

p Application.keys # => []
Tim Riley
@timriley
where is this application.rb file located?
And what does Application.config.root return?
Jonah
@jonahx

@timriley, if I test by running an app.rb from the project root (ie, the dir containing system and domain), which looks like this:

require_relative 'system/container'

p Application.keys
puts Application.config.root.realpath

I get the error:

require_component': could not resolve require file for bot_dialogue (Dry::System::FileNotFoundError)

bot_dialogue.rb is the alphabetically first file in the domain directory, so this is some progress. It looks like this:

require 'import'

class BotDialogue
#stuff
end

It errors before it gets to the line puts Application.config.root.realpath in app.rb so I can’t answer your other question.

Tim Riley
@timriley
@jonahx what is the directory that contains your “domain” dir?
Jonah
@jonahx
@timriley the root of the project
Tim Riley
@timriley
I think you should probably make that the value you pass to load_paths!
Your project seems to be structured differently to how most of us have used dry-system so this might be why you’re experiencing some hiccups
Jonah
@jonahx
@timriley I’ll try that now. but for clarity it looks like this:
root
  application.rb
  domain
    bot_dialogue.rb
    bot_reply.rb
Tim Riley
@timriley
@jonahx If you could push a skeleton of this structure up to a GH repo I’d also be happy to try sort it out for you too (if you’re still stuck after trying a few more things)
Jonah
@jonahx
Cool, thanks. Let me make sure I understand this conceptually… Is config.root supposed to be the project root, or something else? And what is load_paths! supposed to specify?