Jump to content

Could lv-venv be used for other non-VIP dependencies?


Thoric
 Share

Recommended Posts

I have an unusual thought, which I'm close to dismissing but penning here in case it has merit and warrants further conversation.

I have a reuse toolkit that can't be built by VI Package Builder (compatibility issues with VIPB 2017 and VIMs) so it's currently a packed library lvlibp. It's technically a toolkit of VIs, but without a palette (I would like it to have a palette). It's similar to a package, as per VIP qualification, because:

  • It's a package of VIs to be called by the Project
  • It ought to be installed into the LabVIEW IDE and not the project source code folder
  • It has no need to be included in SCC

So I wondered if it could be installed into lv-venv? Maybe a custom subfolder, ideally managed by Dragon too. Doing this makes it local (virtualised) and project specific. Allows me to use future versions on future projects without interfering with existing projects. Avoids including it in the project source code folder and hence also SCC.

I think also it might be good to have it, optionally, appear in the Project view under a virtual folder, perhaps labelled "Custom Virtualised Dependencies", so that the VIs are included in the Project and hence Quick Drop etc.

Just wondering what others think. Happy to be told I'm just dreaming 😄

  • Like 1
Link to comment
Share on other sites

Sounds interesting. I'd be curious to learn more about what these Vis do specifically (or even a hypothetical example).  I'd also be curious about whether the toolkit could actually be packaged into a VIP.  We've been exploring better compatibility with PPLs.  Maybe you could share some details (even offline if you prefer).

Link to comment
Share on other sites

Quick reply: The toolkit is a class for creating AWS Version 4 signatures and handling REST API method calls (there were some things missing from the NI offering, so I wrote my own). The tool includes a dependency to JSONtext which includes a VIM which confused VIPB 2017, the version I'm currently building re-use code within. I understand the VIM issue was resolved in VIPB 2020.

So although I wanted to create a VIP, it's a PPL currently. Versioned, distributed manually to projects and included in a non-version-controlled support folder (a bit like lv-venv!) alongside the source.

I manually add the lvlibp file to the Project as an item so that it's loaded and available through QuickDrop.

Link to comment
Share on other sites

21 hours ago, Jim Kring said:

I'm curious if there's anything holding you back from upgrading to VIPM 202x?

The lack of a Pro license for that version. My place of work has only VIPM 2017 Pro licenses because that's the year we standardised on for our development work (since 2017). A major update may be on the cards, but it's an exhausting effort we're putting off as long as possible.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.