SAS Packages Framework, version 20201101

[yabwon]

Hi,

just for your information, the SAS Packages Framework, version 20201101, was released. As usual the SPF is available at: https://github.com/yabwon/SAS_PACKAGES

In the GitHub's readme.md file I added a list of locations where the SAS Packages Framework is used. If you want to share that you are using the SPF let me know and I'll update the list.

What's new:

• In the %generatePackage() macro two new parameters sasexe= and sascfgfile= pointing the location of the SAS binary and the config file were added.
  • The first points location of a directory where the SAS binary is located, if null (the default) then the !SASROOT is used.
  • The second points location of a file with testing session configuration parameters, if null (the default) then no config file is pointed during the SAS invocation, if set to DEF then the !SASROOT/sasv9.cfg is used.
• Documentation updated.

[EDIT:] Important: The default GitHub repository changed from: master to: main

Available packages:

• SQLinDS (version 2.2)
• macroArray (version 0.7)
  • The %mcHashTable() macro was added to the package.
• DFA (version 0.2)
• BasePlus (version 0.8)
  • New macros %dedupListS(), %dedupListC(), %dedupListP(), %dedupListX(), and %QdedupListX() were added to the package.
• dynMacroArray (version 0.2)

New package added:

• MacroCore [version 1], a macro library for SAS application developers. Over 100 macros for Base SAS, metadata, and Viya. Provided by the SASjs framework (thanks @AllanBowe !).

[ChrisNZ]

@ChrisHemedinger Still not keen to propose this internally, as a standard feature provided by SAS Institute?

[ChrisHemedinger]

@ChrisNZ It is an excellent approach for code reuse and collaboration.  Thanks to @yabwon for developing and sharing.

It has caught the notice of some developers here at SAS -- mostly admirers, but I'll continue to advocate for any opportunity to adopt.

[yabwon]

An edit and note added:

Important: The default GitHub repository changed from: master to: main

Bart

[yabwon · Accepted solution]

Just for your information. The SAS Packages Framework, version 20201103 was released today. The main issue provoking this very quick update was a bugfix for SAS 9.4M5 related to the following Problem Note: https://support.sas.com/kb/62/037.html
All macros using MD5() function should now run on M5.

Packages recompiled with the new version of the SAS Packages Framework:

• SQLinDS (version 2.2)
• macroArray (version 0.7)
  • The %mcHashTable() macro was added in the package.
• DFA (version 0.2)
• BasePlus (version 0.9)
  • New parameter mcArray= added to the %getVars() macro.
  • New macros added:%dedupListS(), %dedupListC(), %dedupListP(), %dedupListX(), and %QdedupListX()
• dynMacroArray (version 0.2)

Thanks to @PaigeMiller for pointing that bug out!

All the best

Bart

[PaigeMiller]

@yabwon 

I have a conceptual question.

I have created a bunch of macros, and I store them in a specific folder and then set my SASAUTOS option to include that folder. This way, I don't have to include the macros in my code, and I don't have to %include each macro each time I want to use it. 

For example, here's some code to illustrate a typical usage of my macros

%macro great_big_honking_macro;

      %small_macro1

      %small_macro2

      %millard_fillmore

      %final_macro

%mend;

Furthermore, all of my colleagues who might want to use these macros can modify their SASAUTOS to point to my folder and they can use these macros as well (assuming they have read access to my folder) without making their own copies of the macro and without having to %include each macro. Great!

But my company doesn't allow people in other departments to access my folder. I can e-mail the code to people who don't have read access to my folder, but then they don't have the latest code after I fix bugs or add features, and they have to specifically ask me to send them stuff. Not a good solution. I can put the macros on GitHub, and then they can always download the ones they need, but this isn't as nice and neat as SASAUTOS, if they don't download all the necessary macros from GitHub, their code won't work (and I am kind of new at GitHub anyway, I don't know if they can point to a GitHub folder via SASAUTOs).

So the real question I have about SAS Packages Framework is: does this overcome the mentioned disadvantages I have described? Can a SAS Packages Framework set-up allow anyone who can access GitHub have a similar experience as SASAUTOS?

Additionally, can we limit the packages on GitHub so they can only be accessed by employees of my company, and not by anyone else?

[yabwon]

@PaigeMiller ,

In other words you are asking "if there is any benefit in this?" 🙂 In short words - I think yes. Here are some arguments:

• First of all it doesn't have to be only macro, you can put functions, IML modules, proc proto C routines, and formats, and even data generating code in a package. 
• With functions and formats the SAS Packages Framework automatically updates cmplib= and fmtsearch= options.
• It allows you to organise loading order of the code the way you want it to be. In case of macros it is not that important, but with functions and formats (e.g. a function using a format or vice-versa) order may be important.
• Next thing is that since you have it all in 1(one) file - you won't forget to share "all that is needed" with your peers, so there will be no "it doesn't work because I forgot send one file with code" situations. Other benefit is that you share one file and say: "here is the macro ABC, you use it like this and that" and you don't have to say that there are 73 other macros working in the "background".
• When it is in package it contains additional metadata (like version number or timestamp of generation) so you can easily answer some of "why it doesn't work?" questions - "doesn't work because you have an obsolete version".
• When you provide a help info in your code then the SPF allows users to display this help in the log automatically without digging through files.
• The Framework allows you to load a package, but the package itself can be loaded into the session even if you don't have access to the framework macros.
• If you build the package you can share it between different OSes (in contrary to SAS catalogs which are system dependent).
• At the end you can use %unloadPackage() macro to clean the content.
• You can add dependencies between packages (if package A requires package B to work, the B will be automatically loaded into the session [as long as it is installed/downloaded])

About the GitHub (or any other network location where you decide to put the package) - the %installPackage() macro,  by default, downloads packages from globally available location on SAS_PACKAGES GitHub page. But there is a parameter which allows you to point to the location you want (even one that is only private for your organisation). So, when you update it and make available there other users can get the latest version themselves.

About: "I don't know if they can point to a GitHub folder via SASAUTOs" - I didn't test that one, maybe a filename URL can be a solution here? Sasautos can use a fileref, right?

Hope it's clearer, just in case there is "user's getting started" presentation available: https://github.com/yabwon/SAS_PACKAGES/blob/main/SPF/Documentation/Getting_Started_with_SAS_Packages...

For developer it's bit more complicated so you have to read the article: https://github.com/yabwon/SAS_PACKAGES/blob/main/SPF/Documentation/SAS(r)%20packages%20-%20the%20way...

In any case I'm open to help, ping me off-line and we can arrange a call.

All the best
Bart