Releases: sassoftware/saspy
V3.3.6
This release has fixes for a couple of issues (#293 #294 ) and some more tweaks to try to get more support for MacOS as a client. It adds an append() method to the SASdata object. It fixes an issue where the filename doesn't support binary socket transfer when SAS is running in DBCS mode; translated SAS sessions. That caused sd2df to fail, Also added support in the STDIO access method to handle Attention Handling in these other language SAS sessions too. Added support for allowing proc printto in a submit, to help support executing batch SAS scripts (.sas files). There is a new option on submit so saspy will submit a proc print 'undo' to set the log and lst back for saspy at the end of the submitted code. Added a section to the documentation to address this and other limitations or work arounds for special case code submissions. Also a fix in the HTTP access method for authenticating to Viya.
V3.3.5
This release has a few fixes and a rework to allow the STDIO (over SSH) access method to work from a Mac. The MacOS version of Python is missing a number of os module methods. waitid was one used in the STDIO access method, which is missing. I reworked the access method to use waitpid, which does happen to be in the Mac version, and now STDIO over SSH (SAS doesn't run locally on a Mac) runs fine from a Mac client. IOM from Mac to a workspace server has worked the whole time, and, of course, the HTTP access method to SPRE in a Viya install should work too, unless Mac Python is missing something about the HTTP Client module; I haven't tried as I don't have a Mac.
There are a couple fixes for the upload and download, where they could hang if SAS couldn't make a socket connection back to the client. This is still STDIO over SSH, and the right way would be to use rtunnel in the config def, but if you don't they would hang. Now there's no hang and a clean error returned in the log.
V3.3.4
So, the new jars didn't upload to pypi. Needed to add them in the setup.py file. So, now it's V3.3.4 on pypi and here.
V3.3.3
V3.3.3 now has the IOM client .jar files included in the repo!!! This means no more classpath in your configuration definitions! No more trying to find the .jar files on the remote SAS server and copying them over to your client! This has been a long time coming, and it's finally here now, at least.
saspy will now create the classpath internally, based upon the install path of saspy, as all of the required jars are in the install directory. The only case that requires intervention is if your workspace server is running encrypted. The 3 jars (in the doc) required for that, must be gotten from your SAS install. But, when you put them in the saspy/java/iomclient directory, the classpath will be complete for you. So if you need those 3 jars (I can't put them on github), just copy them from your SAS deployment into the iomclient dir in the saspy install (with the 4 required jars that are now there) and the classpath will be taken care of for you.
This is the only change for this release. It deserves it's own version! :)
V3.2.1
This release continues the enhancements from 3.2.0 surrounding creating and modifying SAS Data Set attributes.
labels= is added to sd2sd to assign labels to the variables. New rename and modify methods were added to the SASdataset object. Rename should be self-explanatory, while modify allows you to assign dataset or variable labels, assign formats and informats, and even rename variables. There are some other fixes and minor enhancements tool check out the commits for those.
V3.2.0
This release has some new enhancements w.r.t. date, time and datetime processing; specifically with the df2sd and sd2df methods. It also has enhancements to sd2df_[CSV | DISK], to allow for control over the creation of the dataframe; specifically allowing you to override the data formatting and dtype definitions of the dataframe. This is an advanced feature and is documented in the advanced features section of the doc, along with the date, time, datetime enhancements: see the corresponding sections in https://sassoftware.github.io/saspy/advanced-topics.html#
There are also some fixes for a few issues. This release also eliminates the requirement for IPython and pygments from the install. This was something requested quite some time ago, and after implementing support for Zeppelin and Databricks, the IPython requirement was eliminated in the runtime. I addresses the pygments runtime also, so for minimal python installs, saspy will no longer require either of these (and all of their requirements) to be installed.
V3.1.9
This release contains a workaround for a bug that is in SAS 9.04 M5 (Maintenance 5). This bug in SAS affects the sd2df methods of saspy. The data step code that is generated by these methods (MEMORY and DISK), can be affected by this bug, when the SAS session is running in a mutibyte encoding and the data has mutibyte character data. Single byte SAS sessions are not exposed to the bug. The CSV method of sd2df generates Proc Export code, but proc export generates data step code, which may or may not be affected by this bug.; again, only with mutibyte data. At the time of this writing, there is not a hotfix available for M5, so this release of saspy has the following to work around this problem.
saspy will check the version of SAS that it connects to and the encoding that SAS session is running in. If it is M5 and a multibyte encoding, a note will be issued and a configuration option, 'm5dsbug', will be set to True. This option causes alternate data step code to be used in the MEMORY and DISK versions of sd2df. This option can be set explicitly in the configuration definition, or specified on the SASsession method, like any other config option. If set, no message will be displayed and the setting (True or False) will be honored. If/when a hotfix is available for SAS, and applied, you can set m5dsbug to False and everything will behave as before. If you run M5 in a multibyte encoding but only have single byte data, you can set it to False also, as the bug only happens with multibyte data. This problem was found when tracking down Issue #274
V3.1.8
This release just has a couple new WAY COOL features :) Actually these have been a long time coming, and I only just finally got around to added them. As you know, submit() returns a dict, with LOG and LST. But then what? what's the next thing you have to type? Why bother? So, now there's submitLOG() and submitLST(). Guess what they do!
And, submitLST has an option, method=['LISTONLY', 'listorlog', 'listandlog', 'logandlist'] yes, you should already guess what these do too, but I'll tell you anyway. The default just shows the LST, even if it's empty. So, listorlog is good when you expect output, but in case there's nothing, you would then look at the log to see if there was an error or something; so that's what it does; shows the list if there is one, else the log. The other two show both, in the order you choose.
There's also a similar fix for methods which only render their output (hist(), bar(), series() ...). If these methods have nothing to render (LST was empty), then clearly something is amiss. So, in that case thy now display the LOG, which likely contains an error. Same thing you would do yourself if they rendered nothing; print the log looking for the error!
The third thing in this release is a performance improvement to the new sd2df_DISK() method. Found an optimization in the datastep code I'm generating which happens to run faster.
V3.1.7
This release has a lot of enhancements. and fixes. There were some bugs found with the use of obs, firstob in head/tail/obs methods which are now fixed. There is a fix in the IOM access method which catches a crash when transcoding errors happen in the SASlog when it's received in the IOM client. The opts= option for the sd2df_CSV methods is now supported appropriately (for proc export options). There is also a new sd2df method; DISK (sd2df_DISK()). This is a hybrid of the original MEMORY and the CSV versions. It uses the proprietary MEMORY algorithm, which handles embedded delimiters, LF, CR, Null, .... better than the CSV, but persists the data to disk and has pandas read the disk file, like the CSV method, which significantly improves performance for large files. There are also a lot cleanups to the Doc. There were issues with the docstrings where sphinx wasn't generating the method signatures, which is now fixed. There's an enhancement to symget where you can explicitly specify the result data type. And also support for table names that don't conform to the SAS Version 7 restrictions.