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
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
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
- #ecto-query
- #elixirconf-us
- #blog-post
- #ai
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
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.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
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.