Why? Because you don’t want to review the entirety of Ecto’s source? Would you be willing to review the Changeset module?
I know that Ecto is a large library, but:
- Compile times are pretty good
- Disk space is very cheap these days (not cheap enough to run a full bitcoin node, for example, but certainly cheap enough to store Ecto inside your project)
Splitting Ecto into two packages brings an additional maintenance burden to the Ecto developers: two repositories, two issues trackers, two test suites, two sets of versions to manage and release, two libraries that should evolve in lockstep and which now have independent releases, two sets of guides, etc. It might have the good side effect of making the Changeset stand out on its own, but is it worth it?
I see people decrying npm’s micro packages as a horrible thing and wishing Javascript had a larger standard library so that there would be no need for such deep dependency trees. At the same time there is this push to split packages into the “least usable unit” until we get the likes of lodash
(each of which exports a single function, with the package configuration taking up more space than the actual code - yes, JS has a different set of constraints, but still). In all fairness, these might be two distinct groups of people, of course.
What I see here is the following: Elixir has an excellent standard generic data management library called Ecto. This library contains functionality both to deal with data on its own and on to interface with external data stores. And now people are talking about splitting it into two packages, so that projects that depend on one part don’t have to depend on the other.
I’m not an Ecto developer, so this doesn’t affect me directly, but I don’t think the minimal advantages of splitting the packages are worth the maintenance burden just to say that you don’t “depend on Ecto”. Is this just about “bragging rights” about how minimal a program is? Is it a question of being easier to review a smaller number of modules (Changeset) vs a large number of modules (Ecto)?
With Elixir’s very principled approach to metaprogramming this doesn’t seem like a very compelling reason: the effects of a module is necessarily local unless it’s imported or used. We’re not dealing with Python’s level of monkey patching and thread locals.
I wonder if this decoupling thing isn’t being taken too far sometimes. My Elixir code depends on the Standard Library, of which I use only a couple modules per project. Should we split that? (hint: look at JS for the answer).