mikehostetler
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?
Where Next?
Trending in Dev Env & Tools
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimamik
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?
LostKobrakai
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.
mikehostetler
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_connectandjido_connect_google- where thegooglepackage contains connectors for all of the Google Services.This would present the option of adding a dependency for
jido_connect_googlethat 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.