huginn_agent icon indicating copy to clipboard operation
huginn_agent copied to clipboard

Should we port more core Huginn Agents to be gems?

Open 0xdevalias opened this issue 8 years ago • 6 comments

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

0xdevalias avatar Mar 07 '17 22:03 0xdevalias

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.

cantino avatar Mar 08 '17 13:03 cantino

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.

0xdevalias avatar Mar 08 '17 21:03 0xdevalias

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.

cantino avatar Mar 09 '17 02:03 cantino

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.

0xdevalias avatar Mar 09 '17 03:03 0xdevalias

I think huginn_agent is generally ready to be used. We already have a few 'external' people using it and it seems to be doing it's job well.

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 ENV variables.

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.

dsander avatar Mar 09 '17 09:03 dsander

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.

0xdevalias avatar Mar 09 '17 19:03 0xdevalias