Hi everyone,
I just wanted to check, does the Keysight Package Manager support compressed file format such as .7z? For example, we package and compress into 7z format and then rename as a .TapPackage. Will this be feasible and can it be installed as a test plugin?
I know .zip format works, which is what we are currently using, but I am curious if 7z is supported as well. I tried it but it wasn’t working, hence I wanted to check if anyone knows.
Thanks for the help in advance!
Hi Antonio,
OpenTAP and the Package Manager only support the .zip format, and there are currently no plans for supporting other formats.
I don’t really understand the benefit of supporting other formats since all packaging and extraction is usually done by OpenTAP. If you have a use-case where supporting other formats is required I would love to hear it!
Hi @antonio.quizon as @alexander.larsen mentioned, we generally recommend just using the: tap package create command to generate the .TapPackage files. And then OpenTAP can automatically handle the extraction. This simplifies the workflow, and there is also some intelligence built into that process. I’m curious what your use case is for manually zipping the package and changing the extension.
Hi @alexander.larsen and @brennen_direnzo , thanks for the information!
We have some pipeline that compresses assemblies in a .7z file, and reason we chose 7z is because it has a better compression ratio resulting in smaller compressed sizes. I just wanted to check if it was possible to install these assemblies using Keysight TAP as a test plugin but in 7z format.
Would it be possible to know what kind of compression is used in tap package build ?
Brennen misspoke earlier; the command is tap package create, and not tap package build
In short, it is not possible to install plugins from a package in 7z format, and it is very unlikely that we will support it.
Implementation-wise, I think it is the wrong approach for OpenTAP to try to support different archive containers. Even if OpenTAP supports a given format, building TapPackages in that format will cause issues for all other package manager implementations, for one, and older versions of OpenTAP will be unable to extract such packages.
If what you are really interested in is a better compression ratio, 7zip uses the LZMA compression algorithm, but there is no reason a zip archive couldn’t use LZMA as well. But really, this is a matter of use cases. A higher compression rate means compression and extraction is more costly, and as it happens, OpenTAP very often extracts compressed packages in order to parse the contents of the contained package.xml file, so this is not without cost.
For example, if you run the comand tap package list --repository C:\Users\antonio\Downloads, OpenTAP will extract every .TapPackage in your downloads folder in order to detect the name and version, so I’m sure you can see how adding this feature could affect performance in many places.
OpenTAP uses the built-in ZipArchive API in C#. The source code is available here:
Hi @alexander.larsen ,
Thanks for the informative answer!
I agree with your reasons, and that supporting 7z might not be practical for the Package Manager. I am aware that 7zip uses the LZMA compression algorithm. However, as far as I am aware, the built-in ZipArchive does not support specifying the compression algorithm to be used, hence wanted to see if we could use 7zip.
Unrelated to OpenTAP, do you know what is the compression algorithm used for the built-in ZipArchive? 
Other than that, I believe I got more or less the answers that I need. Thanks you so much again!
You are right, the built-in ZipArchive does not support different compression algorithms. To my knowledge it uses DEFLATE.
I was speculating if it would be possible to replace ZipArchive with a different implementation which would allow different compression algorithms in a backwards-compatible way, but I must admit that I am not sure whether or not that is possible.
Thanks for reaching out!
How about including the .7z file in the TAP package, creating an exe to unzip them, and calling that exe from PackageActionExtensions?
<Files>
<File Path="MyPlugin\binaries.7z"></File>
<File Path="MyPlugin\UnzipBinaries.exe"></File>
</Files>
<PackageActionExtensions>
<ActionStep ExeFile="MyPlugin\UnzipBinaries.exe" ActionName="install"></ActionStep>
</PackageActionExtensions>
@alexander.larsen Theoretically, if you could detect the compression algorithm of the file, you could abstract away the implementation, create a factory class to instantiate whichever implementation for the detected algorithm, add a new implementation class for each compression algorithm supported, and that should be backwards-compatible, as it would behave the same for existing packages. For 7zip using LZMA, I think you’d have to use 7zip itself (the executable 7za.exe), as I don’t think you could call it directly from C#.
@david-wsd Would that allow it to work with PackageManager to view the metadata, like Alexander was describing?
Would that allow it to work with PackageManager to view the metadata, like Alexander was describing?
Can you point me to where Alexander is describing metadata? I’m not sure I see it.
This is the behavior I was referring to.
Got it, thanks. I don’t believe the name and version would be affected, since they come from package.xml which is still intact in my scenario.
But one thing that would be affected is Package Manager’s listing of plugins within the package, since it wouldn’t be able to search inside the 7z file for binaries containing plugins. I think that’s a cosmetic issue though.