Saspy

Added

- `None` Nothing added

Changed

- `Tweak` Cleaned up a few bit of documentation. Fixed a link in one section. Nothing significant or different.

- `Tweak` I moved a couple methods out of the individual Access Method modules and into the base module.
Over time, I had been able to make these be the same code in each access method, so now it's cleaner to have
the single implementation in one place instead of 4 places. No changes are required in user code.

- `Tweak` Modified a lookup in the HTTP access method to be more specific, in case something changes in the
API over time. Just getting a link from the list returned by Compute. Nothing changing from users perspective.

- `Tweak` Added some instructions to a couple of SASsession Exceptions to point users at the documentation.
Added messages pointing to the Configuration Doc, the Troubleshooting Guide in the doc and a message to open
an Issue on the saspy github site if needing more help.

Fixed

- `None` Nothing fixed in this release.

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Tweak` Cleaned up a few bit of documentation. Nothing significant or different.

Fixed

- `Fixed` Some time ago, when the Python process terminated (normally), my __del__ methods on SASsession
objects would be called, and I would cleanly terminate the SAS process that was attached. That isn't behaving
as it used to, at least with the HTTP access method for Viya. So, I've added code to explicitly register
a termination exit routing where I then call my cleanup, and that now is behaving as expected for all three
access methods. The SAS process is cleanly terminated before Python finally terminates. So, this is working
as it used to again.

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `None` Nothing changed

Fixed

- `Fixed` A bug was found in df2sd where having a variable of all blanks caused errors in the data step
being used to read in the data. An empty or missing var is handled, but a multibyte blank string wasn't being
handled the same, required, way. This release fixes that bug in all three access methods.

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Enhancement` Added support for Proxy Authentication using user/pw. Support for having a proxy server ahead
of Viya was added in version 4.5.0, and in this release, support for authenticating to that proxy with user/pw
was added based upon a user request. This is documented in the HTTP section of the Configuration documentation.

Fixed

- `Fixed` A minor fix for a case where a unit test was producing a resource warning. I couldn't reproduce this,
but the fix was trivial and it fixed the users case. This was for issue 543.

- `Fixed` A fix in the STDIO access method to explicitly use 'localhost' in the filename statement generated for
dataframe2sasdata() instead of using blank hostname. This was causing an issue for a user with multiple network
adapters and an unusual configuration. Explicitly using localhost is the correct path for this since SAS and Python
are on the same machine, so using the loopback adapter is the right choice.

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Tweak` I adjusted the doc regarding the classpath and the encryption jars; separating the two so that
it was more obvious and so that I could point to the more specific section depending upon the question.

Fixed

- `Fixed` Issue 541 showed a deadlock situation in the STDIO Access Method when the generated code for a
sd2df() call was long enough to block python trying to write that to STDIN because SAS was blocked writing
it out to the LOG, STDERR. So I addressed this so that the deadlock won't happen anymore. This requires no
code changes on your part.

Removed

- `None` Nothing removed

Added

- `Enhancement` Viya has been evolving since I first introduced the HTTP Access Method to connect to SAS
w/in Viya (SAS Compute Server). The current versions are configured with TLS (SSL) by default, and there are
different ways the system can be configured for this. SASPy uses the Public REST API to interact with Viya.
This means HTTPS communication and than means CA Certificates both server side and client side. The best approach
with the latest Viya is to configure it with your companies CA Certificates that are already in use on your clients.
But, if using Viya generated certificates, then these need to be distributed and installed in the right places on
all client machines (that'sa easier said than done). For this case, I've added a new Configuration Definition key,
`cafile`, which can be used to specify the location of the Viya Certificate bundle (the path to that .pem file),
so that HTTP from python will use this certificate to create a Trusted connection. This access method has had the
`verify` key to control whether the connection is to be verified or not (Trusted). With Verify set to True, it now
fails if the connection cannot be verified. If False it doesn't try to create a verified connection, same as before.
The default it still to try and if not verifiable, fall back to unverified; same as it has been, since the original
Viya certificates were not CA Verifiable.

Changed

- `Tweak` Update readme and correct typo by BrokenStreetlight in https://github.com/sassoftware/saspy/pull/538

Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

New Contributors
* BrokenStreetlight made their first contribution in https://github.com/sassoftware/saspy/pull/538