Need Advice: Hex Package release plan & cadence

Chat & Discussions Dev Env & Tools
,
1

TL;DR;
Best practices for shipping an ecosystem of connector packages to Hex in a responsible way?

Background
I have a project, jido_connect: GitHub - agentjido/jido_connect: Integration and connector framework for Jido host applications · GitHub

It is a library of Jido Actions and Primitives for connecting Jido Agents to services such as Google Workspace, Github and Notion.

The project is organized around a base hex package: jido_connect and then adapter packages, such as jido_connect_google. The list of packages is growing - I’m up to 30 plus connector packages.

I have NOT published any of the jido_connect packages to Hex yet. I am cautious to simply ship 30+ packages due to the (personal) commitment to maintain them. The code is being used in my personal projects and in several Jido ecosystem projects - I’d consider it a reasonable BETA quality.

My Hesitation
Personally, if I ship a package to Hex, I’m committing to maintaining it (unless I formally deprecate it). I’ve done this across the Jido ecosystem and am already managing several packages.

I also don’t want to be spammy to Hex and I don’t want to create such a surface area that the maintenance burden becomes overwhelming.

On the contrary, there are users of this code that would like to have Hex packages in a few limited cases. The base package with the DSL and shared behaviours (jido_connect) is a good candidate - with the guidance to then either add dependencies via Hex or vendor the code.

Thoughts?

3 Likes
2

Membrane had this problem before, managing around 100 packages dependent on each other. I think it quickly became very hard to maintain, and the hot take I have is - maybe the drawback of having a single hex package with a bunch of modules as sub-packages is better?

1 Like
3

You can take a look at swoosh and how they handle adapters. It’s not perfect, but it’s a great way to handle in package management of optionally used code/dependencies.

3 Likes
4

Membrane and Swoosh are great examples to look into - thank you!!!

Before researching both of them, I am leaning towards re-organizing the repo a bit to group functionality into package-sized groups - so I could publish both jido_connect and jido_connect_google - where the google package contains connectors for all of the Google Services.

This would present the option of adding a dependency for jido_connect_google that carries a bit of extra code - but isn’t the end of the world.

Then, I will add a documented path to add a GIT based dependency that could focus right into the connector required, or show a path to vendor the code right into the final project.

I’m really feeling the limitations of Mix here - but this feels like the best road forward.

1 Like