Saspy

Added

- `None` Nothing added

Changed

- `None` Nothing changed

Fixed

- `Fix` The user contributed method sd2pq() had a bug in that the signature had a default dictionary declared,
but that persists as an independent object, and the method conditionally assigns other key:values to it which
then persist, incorrectly, in subsequent calls. See issue 611 for details. This version fixes that by defaulting
to None in the signature and using a local variable to provide the actual defaults and other values.

- `Fix` Per issue 612, I've added `parquet` as an optional requirement for the SASPy install, so pyarrow
can be conditionally installed if wanting to use the new user contributed sd2pq() method. I also wnt ahead and
added a conditional install for pandas, via `pandas`, since I never added that to the condition install list
and it's also not a requirement except for if using the sd2df() and df2sd() methods. This doesn't affect any
behavior.

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `None` Nothing changed

Fixed

- `Fix` The HTTP authorization interfaces keep changing and an internal user found a code path that didn't
provide the expected behavior. In order to still support older versions of viya 3.x, which don't have the SASPy
client_id and only supported user/pw authentication (that's changed in more recent 3.5 versions), I had to use
a different internal client_id. However, that client id doesn't support all the things, specifically refresh token
in this case, that the SASPy client id supports. The path through authentication in saspy when using user/pw and
providing client_id didn't use the client id you provided, but rather used the old internal one. So, this fix
simply allows you to provide a client_id (`SASPy` or other), and user/pw as the means to connect. Authorization Code
authentication uses the SASPy id by default (which supports that) as well as with any client_id you provide, so it's
only the user/pw case with client_id being provided that had to be fixed; it now uses the client_id you said.
Until I no longer have to support the old Viya 3.x versions, you do need to specify client_id='SASPy' in order to
get the refresh token, which I do use to automatically refresh your auth token so you don't have it expire after 1
hour, which they changed it to recently.


Removed

- `None` Nothing removed

Added

- `Enhancement` Per a user request. I've added support in the sd2df* methods for dealing with SAS dates and datetimes that
are out of range of Pandas Timestamps (pandas.Timestamp.min, pandas.Timestamp.max). These values will be converted to NaT
in the dataframe. The new feature is to specify a Timestamp value (str(Timestamp)) for the high value and/or low values
(tsmin=, tsmax=) to use to replace Nat's with in the dataframe. This works for both SAS datetime and date values.
For instance, given a SASdata object: sd.to_df(tsmin='1966-01-03 00:00:00.000000', tsmax='1966-01-03 23:59:59.111111')


Changed

- `None` Nothing changed

Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Note

- This is just a note to acknowledge that the minor version jumped from 15 to 100. What that about!?
Well, glad you asked ;) This is the 100th release of SASPy, in under its almost 10 years in existence. So, I just
thought I'd skip a few minor releases to identify the milestone. It's been a privilege to have created and supported
SASPy this whole time, and to have helped and supported all of our users who use it!
Tom

Added

- `Enhancement` A user contributed method `sasdata2parquet` (sd2pq), which is like sasdata2dataframe, but for data too
big to fit in a Pandas DataFrame (not enough memory). This method streams the data over, like sd2df but it writes the data
out as parquet file(s) so that it can then be access in Python by Arrow. It was designed specifically for the users use case,
but it can be used for simple situations as well. There are a lot of parameters, but most default so they aren't needed. It
can be called as simply as: sas.sasdata2parquet('parquet_file','cars','sashelp'). Se the API doc for more.

Changed

- `Deprecated` In version 5.13.0, the JWT authentication mechanism for the HTTP Access Method (Viya) was being deprecated,
so a warning message about that was added to the code path. It turns out that this is being deprecated only for connecting to
Viya using the default SASPy client_id. If however, you have created your own client_id that can use Azure JWT's to connect, then
you can continue to connect and authenticate with the JWT mechanism by providing that client_id, along with the client_secret
and the jwt to SASPy. Those are all existing configuration keys that have been there since before had an internal client id that it
defaults to.

Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Enhancement` Per a user request (see issue 603 for details), in the HTTP and IOM access methods, there is
now a new boolean parameter `loglines` on the submit() method which changes how the LOG is returned. Of course the
default is Fslse to preserve current behavior. The user wanted a list of dictionaries for each line of the log, which
is returned from both the HTTP and IOM API's. The dictionaries have the `line`, which has the LOG contents for that
line, and the `type` which contains identifiers like NOTE, WARRNING, ERROR, TITLE, SOURCE ... See the Issue for
details of what to output is like for each of the access methods, as the API's don't return identical information.
The STDIO (SSH) access method can't return this as there is no API for that.


Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Enhancement` In the HTTP access method, the upload method may encounter an error from the server when the file being uploaded
is bigger that is allowed by the server. This previously resulted in an unclear failure. I now catch this and throw a clear exception.

Fixed

- `Fixed` A bug was found with the append method of the SASdata object. When appending a Dataframe, the method uses df2sd to
transfer the data to SAS to then proc append it. After, it deletes that SASdata set it created. The method also allows you to
provide a SASdata object to append, but it didn't check and deletes that SASdata set too. That should not have been happening.
This is fixed in this release and only deletes the data set if it was temporarily created from the Dataframe.

Removed

- `Deprecated` A new requirement from Viya 4 is to deprecate the Azure JWT Authentication mechanism for SASPy. In a future
version of Viya this will no longer work. I've added this to the doc and issue a warning when trying to use this, in this release.
Support for this will be removed in a future release.