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

V4.7.0

[4.7.0] - 2023-02-08

Added

• None Nothing added

Changed

• Enhanced The estimate statement in at least some procs is allowed to be specified more than once, unlike most proc statements.
  There was previously no support for generating a given statement more than once. Estimate= now allows a list of strings and will generate
  an estimate statement for each string in the list.

Fixed

• Fixed symget(name) returns &name if the marco isn't defined, which is what SAS prints out. So I fixed symget to issue symexist
  first and if not defined issue a warning and return None, which is what it should have been doing all along.

Removed

• None Nothing removed

V4.6.0

[4.6.0] - 2023-02-01

Added

• Added @dmsenter89 added support for Proc MI in the SASStat package. Also, added tests for this in the Stat testing file.

Changed

• Enhanced Made a significant performance improvement in the IOM Access Method with reading the log back from the SAS session.

• Enhanced @ShuguangSun enhanced the run_sas script to support executing multiple scripts in one call

Fixed

• Fixed @dmsenter89 Fixed a number of things with Proc code generation for methods in the SASStat package and some minor things for all
  analytic methods. Fixed statements for Proc Factor.

• Fixed @dmsenter89 Fixed a number of things in the Stat testing file.

Removed

• None Nothing removed

V4.5.0

[4.5.0] - 2023-01-12

Added

• Enhanced Added support in the HTTP Access Method for if there's a proxy server set up to get to the actual Viya deployment.
  There's a new proxy keyword in the config used to provide 'host:port' of the proxy.

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V4.4.3

[4.4.3] - 2022-12-23

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fix The changes for the last release caused one issue w/ unverifiable certificates, where the error isn't
  thrown when the connection is created, needed to add a connect() call at that time to catch the error; that was happening
  before, in a call I moved till later, which is why the error wasn't being caught on the creation where I was checking for it.
  Again, no coding chages for anyone, just made it throw the error where I was checjing for it.

Removed

• None Nothing removed

V4.4.2

[4.4.2] - 2022-12-23

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fix I caused a regression with Viya 3.5 from having to rework authentication due to chages in
  Viya 4. This fixes that and requires no coding changes. This fixes issue #500

• Fix I fixed another issue with the same reworking as above that presented in another specific
  case. This fixes that and requires no coding changes. This fixes issue #503

Removed

• None Nothing removed

V4.4.1

[4.4.1] - 2022-12-01

Added

• Enhanced I added a number of security type enhancements to the repo; none of which has to do with
  how the code works, and requires no code changes. This was all based upon OpenSSF best practices for
  Cybersecurity regarding open source repos. You can see the new badge on the home page: in the README.

Changed

• None Nothing changed

Fixed

• Fix I made a fix to the IOM access method based upon a vulnerability scan from the newly added SAST
  tool that was part of the Security based enhancements added to the repo. This requires no code changes.

• Fix I made a fix for the SAS_kernel, which depends upon SASPY to do the work interacting with SAS.
  There was a breaking change in the Kernel interface regarding prompting. I fixed it so it still works
  with previous versions (of course; no breaking changes for my customers!), as well as with the new api.
  This fix addresses SAS_kernel issue sassoftware/sas_kernel#83

Removed

• None Nothing removed

V4.4.0

[4.4.0] - 2022-11-14

Added

• Enhanced @rayewright added a half dozen more ML procs to the sasViyaML package for Viya.

Changed

• Enhanced Added documentation specifically identifying datatype conversions between SAS data Sets
  and Pandas dataframes; both directions. This was added in the AdvancedTopics section of the doc and the other
  couple parts of that section also about data movement were moved to all be contiguous and thus make all more
  clear. No code changes, just documentation.

• Enhanced Added documentation for the IOM access method regarding authentication. The Configurations
  section already specifies how to authenticate with different means, but now there's a part of the doc explicitly
  identifying which methods are supported and the one method that is not supported; SAS Token Authentication.

• Enhanced @andyjessen cleaned up some links in the doc that were still referring to master instead of main
  for the branch they linked to.

• Enhanced The HTTP access method, to Viya, requires a valid authentication token be passes to every request.
  This token is acquired when calling SASsession(). This token had been set to expire after 10 hours. Viya has been changed
  to have these tokens expire after 1 hour, so to keep this from causing problems for SASPy sessions, which can be
  interactive and last much longer than one hour, I've added support to reauthenticate and get a new authtoken prior
  to the current one expiring. This happens as long as the SASsession object is valid and connected. There are no coding
  changes required in user code. This should all just happen under the covers with no requirements on the user or program.
  I did add a method for explicitly refreshing the authtoken, but that should not be required at any time. But, it may
  be of use as a diagnostic in the field if there are ever issues reauthenticating. So, again, no code changes required.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V4.3.5

[4.3.5] - 2022-10-17

Added

• None Nothing Added

Changed

• Tweak Had a PR with fixes to Doc; mostly typos and consistent use of terms. Also fixed a broken link.

Fixed

• Fix Fix for leaked resources. The pipes that are created between subprocess and Python were not being
  released prior to subtask termination. This results in a resource leak that is identified when running with
  settings that report these issues. I clean this up in both the IOM and STDIO access methods, they each had
  similar concerns. No programming changes required.

• Fix Fix for issue 487 where, in the df2sd() method, there was data that contained the data step
  termination string which resulted in the data step, which was retrieving the data and writing it to the SAS
  data step, terminating prior to processing all of the data and then SAS would take the rest of the stream
  as SAS code, which fails miserably and consumes memory with all of the errors going to the log. It also
  terminates the connection to the client. I've also added code in the java client to catch this kind of
  failure so it wouldn't hang, like it was. So this is addressed and fixed in this release, and requires no
  programming changes.

Removed

• None Nothing removed