BSD support

[jayvdb]

It isnt clear whether this package supports BSDs.

There are two lines which mention darwin explicitly, and the reference in setup.py looks like this package only works completely on darwin.

[ludwigschwardt]

I don't have *BSD so I don't know... I would think you don't need it on BSD, as GNU readline is available and linked into the standard Python already.

[yzgyyang]

I can confirm that gnureadline works fine on my FreeBSD-11.1 amd64 machine, but I only tried import it and did some ad-hoc tests.

[jayvdb]

@yzgyyang , did it build a new readline or link again an existing one?

[ludwigschwardt]

gnureadline is designed to link against a static internal version of the readline library, so it should not care about the one installed on the system.

[jayvdb]

One problem is that if gnureadline is installed, it will take over the name readline even if that was unnecessary.

That makes it less desirable to use gnureadline as a backup for missing builtin readline package in a wheel world.

Possible ways around this include

1. setup.py to look for the existence of a real working readline already and bailout as a no-op, or
2. the stub readline.py to import the stdlib readline (like https://stackoverflow.com/a/6032023) and provide that instead if it is not the libedit version.

Both of those involve change which would impact existing gnureadline users.

In the second option, gnureadline users who really need gnureadline and not a native equivalent, should really import gnureadline directly, so IMO that path has negligible impact, but the complexity of importing the stdlib readline and detecting libedit is makes it non-trivial and possibly has some corner cases which impact users.

Is there another option I am missing which would have less impact?

[ludwigschwardt]

Interesting and somewhat tricky questions. I've been down this road before in previous incarnations of this package :-)

I'm curious about the problem you are trying to solve. Is it to have one-readline-for-all à la anyreadline? Or do you have a specific system that needs it?

[ludwigschwardt]

Revisiting old tickets...

John and Guangyuan, is this still an issue for you?

To recap:

• Although it is primarily aimed at macOS, the gnureadline package supports most (all?) Posix systems, as long as it has some form of curses installed. The CI tests run on Ubuntu and macOS. Windows is explicitly not supported.
• I've never tested it on BSD but reports suggest that it does work.
• The package does install a readline module in site-packages but this typically won't override the standard library version of readline, unless the user has a fairly twisted PYTHONPATH... This route provides readline on distributions like ActivePython, which used to ship without any readline module in the standard library.
• The gnureadline package also provides an up-to-date version of libreadline and its extension for folks who already have GNU readline installed, so it is not meant to be a pure fallback option. That sounds more like anyreadline to me (although that package needs some help :-) )

So gnureadline peacefully coexists alongside the stdlib readline, and only gets invoked explicitly or if the user decides to run the brand new override_readline script (still in development).