See #74 (comment) for context.

Before: ~89.03 MB
After: ~89.41 MB

infosiftr@54245c1#commitcomment-15226093

if we go for readline, then we should remove libedit-dev. The motivation for using libedit instead was mostly to avoid readline due to GPL. For some people that is important. I am not impressed over the code quality in readline either so I generally happy to avoid it if possible too.

So my question is: is the readline python module really needed?

#53 is where this was previously discussed, but the main concern there appeared to be using the interactive debugger, not using the core module directly from code.

I don't mind switching to libedit if it's functionally equivalent, but if we make such a change I would prefer to make it across the board (slim, alpine, and standard variants alike). I don't think GPL avoidance is a good rationale for such a choice, but code quality definitely is IMO (and I'm not terribly pleased with readline's handling either in my own usage).

So it really comes down to whether we can safely say that removing support for the core readline module is not going to have a negative effect on our users, and I think if we could find a way to scan some large collection of existing modules for usage of it we could determine that effect and make a more useful, informed decision here. Until such research, I'd be more inclined to say that core modules ought to work out of the box unless there's a way to reasonably get them working after the fact.

Arg, in doing a little more research I see that (frustratingly) the core readline module does support libedit, but only officially on OSX.

Since this is a core module and cannot easily be enabled after the fact, I'm merging. If upstream ever supports libedit on non-OSX platforms, I think we can revisit this.