NI Package Builder Dependices management configuration

[MaximeR]

Hello,

Does anyone understand clearly how dependencies are working for pacakges. It's unclear for me inside NI Package Builder and it's the same inside LabVIEW.

How can I configure the package to requests for example to request TestStand Version 2019 but without taking in count the patch installed?

It can be the same for any package that can have patch. For example LabVIEW Runtime. I need absolutely the LV RunTime 2018 but I don't care if it's the 2018 F1, F2, SP1 f3 for example. Is it possible to configure it like that ?

Thanks in advance.

[Scott_Richardson]

Maxime - 

NIPB:

In NIPB after you add a dependency to an installed package, the default relationship is >= the version of the installed package.

 If you select the dependency as shown above, the Properties pane looks like shown below. In your case the 3rd digit is non-zero, i.e. "19.0.1"...

You can change the Version Type to Custom, and edit the version to be "19.0.0.0" as shown below:

LabVIEW:

You must first unselect "Automatically select dependencies". Then to enable the controls on a package click on a different package and then back to the package to enable the "dependency relationship" controls. Then change the >= version accordingly as shown below so something like "20.1.0.0"

[MaximeR]

Thanks Scott,

Ok, so the version number can be 19 only ? how really works the comparison ?

if I put 19.0.1 and >= for the same package, if a new version of this package is 19.1.0 is it compatible ?

I was thinking that for LabVIEW runtime, if I put 19 and >=, the Run-time 2020 will be consider as compatible, but it's another package name, so it works. If I don't care about the version of a specific pacakge name, why not add the choice any version?

Another remarks, is about package classification. It's seems to be not so easy for NI too.

Sometimes run time pacakges are under runtime, sometimes not. Difficult to filter packages in this case ?

Removing the version in the name can be confusing too :

Without the version in the name, you need to take a look on the version number to be sure to have selected the correct pacakge.

Best regards, and thanks again for your reactivity.

MaximeR

[Scott_Richardson]

MaximeR, NI's based packages are uniquely defined by the package name and the version. For LabVIEW, their package names contain year text, so they are considered different packages and can be installed side by side. Packages with the same name but different versions will upgrade.

NI "package builder features" require all 4 field values in a version field for a package that you build. The field in a package supports the 4 field values plus a suffix and that is what NI's build process uses.

Version comparison is such that 19.0 is less than 19.1, 19.0.1 and 19.0.1f1, so using a version field value of 19.0 and >= would cover all of them.

Most of the packages that have a year version in the name are older installed products from before NIPM, but we show them in the NIPM so that they can be uninstalled. Our naming guidelines is to NOT included versions in package names.

In the filter control in NIPB, you should be able to type "LabVIEW 2019" and it will find LabVIEW in the "name" column, and "2019" in the version column.

[MaximeR]

Ok, thanks for the details.

So in the future, more and more packets will have the same name.

So well understanding the version selection is very important. With driver, like DAQmx, you may be compatible with only a range of version. DAQmx 20 remove support of serie E devices, but if you are using it in a LabVIEW 2019 version, you will need to have a DAQmx 19 version as minimum version. If you don't want to have issue and to have some flexibility on the setup for the user, you have to support any 19.X.X version.

So setting "=" and 19 is going to work or it's not possible to filter major or major.minor release ?

sorry for asking this very specific question, but I'm trying my install on different benches, and I'm facing this kind of compatibility issue and I want to manage it in the best way. I faced on case, where user update teststand to f3 patch, and my package doesn't want to be installed and the message is not clear. At least one needed package is more so we will do nothing for installation... On idea is about this 

NIPM: Add flexibility to selecting version of packages - NI Community

Thanks scott.

[Scott_Richardson]

MaximeR, NI Package Builder support specifying a range for a dependency by adding the dependency twice and editing the constraint and version value, e.g. as shown below:

And this will build the control file list this in the control file:

Depends: ni-package-builder (>=20.5), ni-package-builder (<<20.6)

If you build an installer or feed, Package Builder will attempt to include a package that satisfies that dependency and if previously installed and in the cache or currently installed, it will fail to build.

Setting a version to equal (=) is very restrictive and should only be used if really necessary.