Skip to content
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

Open
0xdevalias opened this issue Mar 7, 2017 · 6 comments
Open

Should we port more core Huginn Agents to be gems? #11

0xdevalias opened this issue Mar 7, 2017 · 6 comments

Comments

@0xdevalias
Copy link
Member

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

@cantino
Copy link
Member

cantino commented Mar 8, 2017

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.

@0xdevalias
Copy link
Member Author

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.

@cantino
Copy link
Member

cantino commented Mar 9, 2017

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.

@0xdevalias
Copy link
Member Author

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.

@dsander
Copy link
Collaborator

dsander commented Mar 9, 2017

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.

@0xdevalias
Copy link
Member Author

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.

@cantino cantino changed the title Is this ready for prime time? Should we port more core Huginn Agents to be gems? Mar 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants