Rename SerialPorts.jl PySerialPorts.jl

[s-celles]

Following JuliaIO/LibSerialPort.jl#20 (comment)
maybe we should consider renaming SerialPorts.jl PySerialPorts.jl which is more explicit about what this package actualy do.

[s-celles]

SerialPorts.jl could first use PySerialPorts.jl and later LibSerialPorts.jl

PS : JuliaIO/Roadmap#3

[mgkuhn]

The name SerialPorts.jl could also be reserved for a future native Julia serial-port library, which might be needed to fully integrate non-blocking serial-port communication with the multi-threading and asynchronous I/O capabilities of libuv and Julia. However, that's a non-trivial piece of work, because POSIX and Win32 have completely different serial-port APIs.

[s-celles]

As discussed in JuliaIO/Roadmap#3 (comment) renaming SerialPorts.jl to PySerialPorts.jl should be considered

A first step could be to create PySerialPorts with exactly same code as SerialPorts and publish it
Then deprecating SerialPorts to ask to use either PySerialPorts if looking at a Python implementation of serial port or LibSerialPort for a Julia wrapper to C library libserialport.

Pinging @KronosTheLate @andrewadare @sjkelly

[KronosTheLate]

I was recently looking for Serial comunications packages for Julia, and found the naming confusing. SerialPorts.jl sounds very straightforward, but requires a Python installation I don't have. Whereas LibSerialPorts sounded more specific and I did not know what the "Lib" ment, but it seems that it is the more straightforward solution for what I have in mind. This renaming would have made it faster and easier for me to orient myself in the package options.

[s-celles]

A @JuliaIO owner https://github.com/JuliaIO should create PySerialPorts.jl repository under JuliaIO
Pinging @andreasnoack @ararslan @tanmaykm @sjkelly and all...

[sjkelly]

I don't really have the time to champion a package rename. Happy to let someone else do it.

When I created this package 6 years ago the name made sense as it was the only general package with this functionality. Apologies for confusion. In the interim I will cross reference libserialport in the readme.

[notinaboat]

It might also be useful to point out in the README that on Linux you can just open the serial port using Base.open

run(`stty -F /dev/ttyS0 38400 raw`)
serial_in = open("/dev/ttyS0", read=true, write=false)
serial_out = open("/dev/ttyS0", read=false, write=true)

[mgkuhn]

@notinaboat That's essentially what a native serial-port package would do on Linux, such that the async I/O facilities of libuv become available. However, it would also have to offer portable wrappers for the POSIX termios.h API, i.e.

speed_t cfgetispeed(const struct termios *);
speed_t cfgetospeed(const struct termios *);
int     cfsetispeed(struct termios *, speed_t);
int     cfsetospeed(struct termios *, speed_t);
int     tcdrain(int);
int     tcflow(int, int);
int     tcflush(int, int);
int     tcgetattr(int, struct termios *);
pid_t   tcgetsid(int);
int     tcsendbreak(int, int);
int     tcsetattr(int, int, struct termios *);

instead of calling the stty command-line tool, and some care would have to be taken with concurrency and task safety for calling these, so they play along well with libuv (especially the drain/flush functions for managing UART buffers).

But Julia also aims to be a multi-platform environment, and while other Unices, such as macOS, are likely to work quite similarly to Linux, Win32 has a rather different serial-port API. And ideally, much of that should be hidden from the user, such that they can move their Julia code between the platforms with ease. That's what the currently used C and Python libraries do, but they bypass libuv.