V5.100.1

[5.100.1] - 2024-07-17

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' (when using user/pw auth) 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

V5.100.0

[5.100.0] - 2024-07-10

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's 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

v5.15.0

[5.15.0] - 2024-06-27

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

New Contributors

• @rainermensing made their first contribution in #608

V5.14.0

[5.14.0] - 2024-06-14

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

V5.13.0

[5.13.0] - 2024-05-16

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.

V5.12.0

[5.12.0] - 2024-04-18

Added

• None Nothing added

Changed

• Enhancement A new requirement in Viya 4 called for a change in the SSO authentication mechanism, to support PKCE. So this
  release provides support for that. There's nothing you have to do, but you will see a different message about the URL you need
  to use to get an auth code to provide, when using that authentication mechanism. In short, every time you want to authenticate,
  you get a new URL (it has its own unique code in it). This is displayed in the log same as the previous URL was, but unlike
  previously, where the url was the same every time for the deployment, and you could already get a code and provide it to SASsession(),
  this is a unique URL every time. So you can't get an authcode ahead of time. Don't fuss at me, I don't like it either. If you need
  help, open an issue and I'll see what I can do.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.11.0

[5.11.0] - 2024-04-16

Added

• Enhancement Per internal tester request, I've added an option for the STDIO access method to provide an amount of time for
  SAS to terminate before killing the process, in the endsas() method. I've always waited up to 5 seconds from the subprocess
  to terminate after requesting SAS shutdown, which is normally fine. If it takes longer, I kill the process. In this case,
  SAS runs with some internal testing options which causes processing at termination, and takes longer than 5 seconds. So I've
  added an option to allow me to wait longer before terminating the process which will allow this extra termination processing
  to complete. This isn't a usual option customers would set, but it's there either way. The option is termwait and it takes an
  integer number of seconds. In this case, the config def required: 'termwait': 60, to get it to work as expected.

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.10.0

[5.10.0] - 2024-04-09

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• Enhancement Per user request, I've added the ability to request a keepalive thread in the IOM access method.
  I added this in V5.9.0, but then found that this could deadlock the IOM access method if the keepalive thread executed while in the middle
  of one of my SASPy methods; which I didn't think would be the case, but I didn't happen to have it happen. When it
  does, it can deadlock everything. So, I'm removing this feature with this release. It just doesn't work as expected.

V5.9.0

[5.9.0] - 2024-04-08

Added

• None Nothing added

Changed

• Enhancement Per user request, I've added the ability to request a keepalive thread in the IOM access method.
  The workspace server has a timeout option (defined in metadata), which usually defaults to 60 minutes. If no interaction
  happens in that amount of time since the last interaction, the Workspace server will terminate itself. I've added an
  option keepalive for the IOM access method that can be defined in the Configuration Definition or on SASsession(keepalive=50) to
  specify you want this thread created and how many minutes in between interactions. So, if you're Workspace server has
  a timeout of 60 min, you can specify 'keepalive' : 50, in your config def to have saspy send a request every 50 min
  so the timeout doesn't happen, and keep your session connected until you terminate it. The default is, of course, the
  current behavior which is no keepalive thread.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.7.0

[5.7.0] - 2024-03-19

Added

• None Nothing added

Changed

• Enhancement Per user request, I've added the ability to CANCEL submit()'ed code in both the IOM and HTTP
  access methods. Until now you would see a message like the following if you tried to interrupt a submit:
  SAS attention handling is not yet supported over IOM. Please enter (T) to terminate SAS or (C) to continue.
  But now, with the ability to cancel long running code, you will see something like this instead:
  Please enter (T) to Terminate SAS or (C) to Cancel submitted code or (W) continue to Wait.
  If you choose 'C' then I can now use the API to tell the server to terminate whatever was being executed and
  come back immediately, so you can then run other code. Also, for IOM, I cancel any code in endsas() so that the
  workspace server terminates immediately instead of only after whatever is running finishes.

Fixed

• None Nothing fixed

Removed

• None Nothing removed