-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we port more core Huginn Agents to be gems? #11
Comments
I think it is ready, but I'm not sure there's a need to convert all Agents over. Perhaps just ones that we think are used less often? It'll be an annoying transition since we don't want to break people. I'm not sure how to do it in a non-breaking way. |
I wonder, if it follows the same naming/DB/etc footprint, would it not be able to be changed over without any direct impact on the end user? Admittedly I haven't read much into how this differs yet/if that would be possible. |
It'd work if we pulled stuff into a gem, then required it by default, but my hope would be to stop loading so many gems by default. |
That would be my ultimate plan too. But I think being able to move towards that, while minimising impact in the meantime, might be cool. And then at the point of cutover, a simple/well tested migration doc, basically telling them how to 'install' the new gems. There's possibly even potential scope for detecting what's setup and notifying in app how to remedy it. |
I think Not sure about moving bundled Agents into gems, I think they should definitely not be external but in the Huginn repository. Having to maintain dozens of Agent gems and their intersecting dependencies could be near to impossible. It would also mean the the users need to update each Agent gem by themselves. If we move some of the more expensive Agents into (internal) gems it would probably make the disabling of Agents easier, instead of having to edit the Gemfile it could be done via Before start with it we should benchmark how much memory and dependencies are required by the Agents in question. If we would save 10MB by disabling 10 Agents I would argue that it's not worth doing at all. |
nods that all sounds pretty reasonable. It'd also be interesting to see how much/little effort it takes to convert the old gems to this format. If it's minimal effort, maybe there would be benefit in just supporting the 'external interface'. Mostly just floating idea here, I don't really have a strong opinion one way or the other on this. |
Was pondering about this the other day.. in particular, if this is ready for prime time, can we convert all the existing agents to external gems?
And then we could maintain the 'default agent collection' in huginn's main Gemfile, and/or vendoring them so they're available.
Would lead to a much cleaner codebase/easier to reason about dependency interactions
The text was updated successfully, but these errors were encountered: