rename VI dependencies

[RocketHacker]

I am getting together a plan to build my large library (1500+ VIs) of reusable code into VI packages and migrate all applications using that code to pull out of VIPM/VIPCs. We must validate changes as we go, and we still have other work to do, so this will be a gradual migration. To make this even more interesting, we're the first adopter of this at our company, so any deployment issues will taint the reputation of VIPM forever, as our managers/counterparts are somewhat skeptical already. ok, now on to my problem...

 

I have already built a few standalone\low-risk components into VIPs and they've work out quite well but now i'm moving on to more significant components and i'm having issues with shared VI dependencies (not VIP dependencies). here's the scenario:

• I build package A.vip and it has a VI dependency X.vi
  
• I build package B.vip and it has a VI dependency X.vi
  
• I have application Applicaiton.vi that has dependencies on A.vip, B.vip and X.vi (X.vi is directly contained in Applicaiton.vi)
  
• When i open Applicaiton.vi, I am unsure which X.vi will be used.
  
• Now, as a consequence of me applying configuration management, I have now completely lost configuration management
  

 

Our deployment may last upward of 6 months, so i cannot get into this situation where we have lost configuration control. This will put us in crisis mode which will only further draw out deployment. also, we test rocket engines. you must always assume that every bug\problem has the potential to spontaneously ignite all propellant on site and result in a pretty bad day.

 

To address this issue, i need to be able to rename VI dependencies only (add a prefix/postfix). I know that you can currently rename all packaged files and this is not a viable solution because it will make it extremely painful to move my applications/toolkits over to VIPs and i need to maintain the same file names between source code/package so that i can switch back and forth for debugging.

 

I would assume that this feature would appear in the "source file settings" area as a separate item called "Dependencies". This would make it consistent with how the NI packed library build configuration dialog looks.

 

i understand what implication this will have if you are using functional globals in dependencies and i'm okay with that.

 

Let me know if you have any questions about this. As i stand right now, this is preventing me from migrating and consequently buying more VIPM licenses...

[RocketHacker]

i apologize, my estimates were a little off. there are 2300 VIs in our reuse library

[Michael Aivaliotis]

I assume that X.vi is located beneath your application source and both packages and source link to this same location?

 

You have a challenging task ahead of you and I can sympathise with your concerns. Assuming the above is true. Here are some recommendations and best practices.

 

• Use renaming during the package build process. - LabVIEW will autolink to the VI with the same name, whether it's in your source or beneath vi.lib. Renaming eliminates uncertainty and cross-linking nightmares. The added benefit of this is it will allow you to have the original package source VIs and the package-d VIs open at the same time without fear of cross-linking.
• If the X.vi is a common component that many use, then that is a good sign that it needs to go into it's own VIP and removed from the source. Then the packages can declare it as a dependency and the application source can link to the packaged version. Everyone's happy and you maintain control.

Now one problem (as you mentioned) is how to "fix" your source so that it points to the renamed installed VIs. Doing this manually can be tedious. At JKI we're working on internal tools that are experimental and can help automate this task. I'll take a look at how we can make these available to you.

 

The idea of controlling the dependency renaming as a separate configurable option is an interesting idea. Perhaps post it to the VIPM idea exchange to get feedback from others.

[RocketHacker]

X.vi is a piece of reusable code that is shared by applications and other reusable code. They all link to the same location.

 

• I can't rename files when i package them. The manual re-linking effort is prohibitive.
  • reusable code is used in reusable code
  • reusable code library is used in 50+ applications
  • no easy way to switch back to source code and debug
    • can't edit the package files directly. due to the differing names, changes can't be easily ported back into version control (SVN)

    [*]coincidentally, the code that needs to be distributed by VIPM the most is used in the most places and is most affected by this problem...

  [*]X.vi will eventually become a VIP. no question about this. The issue is that the process of packaging, deploying and validating each package cannot be performed in a single quick step where the normal rules would apply.

  • workflow is:
  1. 1. build X.vi into X.VIP
     2. re-link and rebuild packages that use X.vi to X.VIP
     3. re-link 50+ applications to X.VIP
     4. update VIPCs for all applications to include X.vip
     5. deploy new VIPCs and update applications on 50++ servers the applications are used on (we use dev environment for most deployments. reasoning is outside the scope of this post)
  • for our code base this process can take days per package. We cannot devote all of our time to this task, so we have to assume that it will get interrupted by more immediate tasks, resulting in the need for code merging, etc.

  Having the ability to easily switch between source <--> package (when the package files are not the same name) would be a viable fix for this problem. Can you PM me with more information on availability of this feature? I have made a lot of promises about VIPM to my management (seemed like a good idea at the time...). Since this is a blocking issue, I need to give them some idea of the plan forward and a timeline to match.

   

  If you need clarification of any of the above, let me know. The more i help you, the more you help me

[RocketHacker]

Vote on the idea related to this ticket here http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/

[Michael Aivaliotis]

What if someone has the package installed and the old non-packaged version. How can you control which one LabVIEW uses?

[RocketHacker]

if the packaged file has renamed its dependencies, there will not be a name conflict with the old-nonpackaged version.

• A.vip
  • has dependency X.vi that is renamed and packaged as A_X.vi

  [*]B.vip

  • has dependency X.vi that is renamed and packaged as B_X.vi

  [*]Application.vi has dependencies

  • X.vi
  • A.vip that uses A_X.vi
  • B.vip that uses B_X.vi

so, as long as we can rename dependencies only, there will be no conflicts. you don't have to worry about using differing versions of X.vi because the version that was included in each instance was (hopefully) exhaustively tested to work when it was packaged

[todd]

I don't understand why you would want three copies of the same VI, with different namespace. Why not:

1) Package up a low-level package (one that doesn't call any other VIs that will get packaged).

1a) If those VIs happen to be in an lvlib, just rename the lvlib file, not its contents - for easier re-linking.

2a) Check one of the apps out of source control

2b) Link the pre-packaged VIs to the ones in the package

2c) Check in the app and the vipc file

[Michael Aivaliotis]

if the packaged file has renamed its dependencies, there will not be a name conflict with the old-nonpackaged version.

• A.vip
  • has dependency X.vi that is renamed and packaged as A_X.vi

  [*]B.vip

  • has dependency X.vi that is renamed and packaged as B_X.vi

  [*]Application.vi has dependencies

  • X.vi
  • A.vip that uses A_X.vi
  • B.vip that uses B_X.vi

so, as long as we can rename dependencies only, there will be no conflicts. you don't have to worry about using differing versions of X.vi because the version that was included in each instance was (hopefully) exhaustively tested to work when it was packaged

 

Sorry if I wasn't clear. The main direction of my question was to the core VIs (not the dependencies). Those are not renamed based on your design. So how would you handle cross-linking in the main packaged code? How do you control which version your app links to. The new packaged code or the old reuse code.

[Michael Aivaliotis]

I don't understand why you would want three copies of the same VI, with different namespace. Why not:

1) Package up a low-level package (one that doesn't call any other VIs that will get packaged).

1a) If those VIs happen to be in an lvlib, just rename the lvlib file, not its contents - for easier re-linking.

2a) Check one of the apps out of source control

2b) Link the pre-packaged VIs to the ones in the package

2c) Check in the app and the vipc file

This would be a good approach. Find the lowest common denominator and build up your reuse from there. Testing and validating as you go along.

 

I assume that you are packaging code that is already in a reuse library and has been tested and functional. You're just repackaging it and possibly adding renaming. You could rerun your tests on the packaged code just to be sure.

 

 

[Michael Aivaliotis]

no easy way to switch back to source code and debugcan't edit the package files directly. due to the differing names, changes can't be easily ported back into version control (SVN)

To address this comment. I would discourage users from saving edits of the packaged code. The same reason I would discourage a user from editing the LabVIEW shipping code under vi.lib. You've broken configuration management. Any edits you make should be re-saved back into the app source folder. Actually, the renaming helps here because the origin of the changed VI can be tracked back to the package it came from. Then at a later time, someone can merge those edits back to the package source and re-issue the package.

[RocketHacker]

agreed. my plan is to lock all package VIs in a post-install action. this will make it pretty obvious which ones are packaged even if they have the same name as the source files

 

here's the idea related to the locking feature http://ideas.jki.net/topic/167870-allow-locked-no-password-protection/

 

 

 

[RocketHacker]

Quick update on this ticket.

 

With the introduction of the PMT (https://decibel.ni.com/content/docs/DOC-30858), we have no issues with renaming files any longer. We no longer need this request fulfilled.