V5.4.0

[5.4.0] - 2023-09-27

Added

• None Nothing added

Changed

• Tweak Changed the doc for saslib() to show how to deassign a libref using this method, as well
  as how it's already doc'ed for assigning librefs. Nothing changed with the method, just documenting how to use
  it for both assign and deassign.

Fixed

• Fixed An internal user found a bug with sd2df() where it was converting character variables values of
  'NA' in the SAS Data Set to NaN in the dataframe instead of them being the string 'NA'. This turned out to
  be due to the interaction of the na_values={...} dictionary I pass in, since I need to normalize the 30ish
  different MISSING Values that SAS has, to individual values to provide Pandas so they are processed correctly.
  The problem, however, is that the default value of keep_default_na= being True, appends my list to Pandas
  list of what it thinks values are for NaN's instead of only using my list. The file is to specify keep_default_na=True
  as well as provide my list via na_values={...}. That is fixed in this release.

Removed

• None Nothing removed

V5.3.0

[5.3.0] - 2023-08-29

Added

• None Nothing added

Changed

• Tweak Changed the value of Context in the HTTP config definitions in the example sascfg.py file to use
  the more likely SAS Studio compute context. This has no effect on any code. It's just an example configuration.

• Enhanced df2sd() now raises an exception (SASDFNamesToLongError) if any of the column names are longer than 32 bytes,
  in the SAS Session encoding, since the data step will fail for those columns and produce errors in the log, but SAS still create
  the SAS Data set, incorrectly. Previously, df2sd returned the SASData object, and issued a message about finding Errors in the log,
  but didn't fail. The resultant SAS Data Set wasn't correct so checking for this and raising the exception is what should happen.
  I also write a message with each column name that is too long, so you know which one(s) need to be changed. And remember, SAS's
  restriction on these names is 32 bytes in the SAS Session encoding, and not necessarily 32 characters of utf-8 from Python.

Fixed

• Fixed I found a bug in the code that parses the authinfo file to find the authkey. It was using startswith(authkey)
  to find the line to use, for the user and password. But startswith() isn't looking at the first word, only so many characters.
  This could result in using the wrong line from the authinfo file. For instance, if you had a line with the authkey of tom1 and
  another line further in the file with authkey of tom, then looking for authkey='tom' would use the first line with tom1 for the
  credentials instead of the correct line starting with tom. Simple fix to parse it correctly so it compares the whole first
  word of the line now.

Removed

• None Nothing removed

V5.2.3

[5.2.3] - 2023-07-28

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

V5.2.2

[5.2.2] - 2023-07-07

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

V5.2.1

[5.2.1] - 2023-05-31

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

V5.2.0

[5.2.0] - 2023-05-30

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

V5.1.2

[5.1.2] - 2023-04-28

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

V5.1.0

[5.1.0] - 2023-04-14

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 #538

Fixed

• None Nothing fixed

Removed

• None Nothing removed

New Contributors

• @BrokenStreetlight made their first contribution in #538

V5.0.2

[5.0.2] - 2023-03-10

Added

• None Nothing added

Changed

• Enhanced The latest versions of Pip complain that setup.py is being deprecated and that using a pyproject.toml
  file (still in conjunction with a setup.py, if you like) is the soon to be required means of building a Python Package.
  This release of SASPy has a minimum pyproject.toml file which seems to be acceptable to Pip. I'm creating this release
  to see if the whole process, from PyPI to conda-forge all work with this change; thus this is the only change. If all
  works well, then great. If not, I'll scrap this and see what else is needed. Obviously I've tested this out and it works,
  other than seeing if PiPI and conda-forge have any issue; have to run it through those to see what comes out. I expect
  there to be no issue, but let's see. Well, v5.0.1 didn't build right for pypi, so take 2 with 5.0.2.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.0.0

[5.0.0] - 2023-02-28

Added

• None Nothing added

Changed

• BREAK This is a breaking change, thus the incrementation of the major digit of the Sematic Version.

The analytic methods (which are really SAS Procs) return any number of results; they produce tables, graphs, plots,
... All of these results are (supposed to be) returned in the SASResults object. This object is implemented by having
the proc code executed in a way that writes all output to an ODS Document. That is an Itemstore file created by SAS.
It's like a blob store with an internal directory structure. There is also a libname engine that can access these
stores, at the directory level. The proc generation code and the implementation of the SASResults object use the
concatenation of all of the directories in the ODS document to access and return the various outputs from the
procedure. Unfortunately, the original implementation of this never took into account the fact that many procs
produce the same set of tables/plots/... for multiple criteria. The names of these objects are the same in each set,
but stored in the document under different directories. A side effect of this is that accessing these through the
concatenated libref only sees, and can only access, the first of occurrence of these same named members. That means
that much of the actual output from these procs has NOT been returned and is NOT accessible from the SASResults
object.

To address this, I've had to learn how all of this works (this is the one part of saspy I didn't write), and rework
how the SASResults object is implemented, including some overly complicated traversal and renaming of these members
in the Document so that they can be returned and accessed via the SASResults object. Now all of the tables/plots/...
will be returned and can be accessed. The change is that now the names of these members are comprised of their
original names and part of the directory structure names (being limited to 32 chars) such that they can be easily
identified as the results for the appropriate criteria.

So, clearly, this is a breaking change for the cases where there were missing results and now the names of the
results have been changed to allow the other missing results to be available. For member names that had no duplicate
missing members, their names are not changed by this. That means that there are cases where this fix does not break
any code; if you had hard coded names of the SASResults list of results. So, new members that had been missing
previously will now be available when they hadn't previously. While names that didn't have missing duplicates won't
change. So the only thing you have to do to your programs, is adjust the name of a result you're trying to access
when that member has duplicates; as all of those members are renamed with the new algorithm. Remember, you get the
list of results by executing dir(SASResults_object).

Hopefully fixing this to return the correct results is worth any code that has to be adjusted. I consider this to
have been wrong to begin with, and so making it right outweighs my aversion to introducing a breaking change.

• BREAK This is a breaking change, thus the incrementation of the major digit of the Sematic Version.
  The SASml method hpcluster is renamed to be the correct Proc name of hpclus, There is no proc named hpcluster
  and this being named wrong caused issues with the test cases, and there was a special check in the code to catch
  this name and change it to be the correct proc name. So, since this release is already a breaking change to fix
  the SASResults for all of the procs, I figured it would be a good time to fix this one wrongly named proc/method.
  If you use hpcluster in your SASPy code, I'm afraid you'll need to delete the ter from it to address this change.

Fixed

• Fixed Fixed a number of problems in the test suits for the analytic procs. There were a number of test cases that
  failed and now pass correctly. There were Viya procs that never ran, even when connected to a Viya deployment. These
  previously failed regardless, and now they run and pass when connected to Viya. None of this affects user code, it's
  just cleaning up the test ware having to do with these Procs (analytic methods).

This also includes re-benching all of the test cases where there were missing results. These all now have all of the
results being returned and the tests now validate all of the correct results.

Removed

• None Nothing removed