Saspy

Latest version: v5.12.0

Safety actively analyzes 624160 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 4 of 7

5.1.0

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

5.0.2

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

5.0.0

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

4.7.0

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

4.6.0

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

4.5.0

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

Page 4 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.