[LabVIEW project window "artefact"]

Thanks for reporting this. We've seen it happen, too, and will see if we can fix the issue.

[Display list of missing required packages]

That's a good point Mariano. Right now, Dragon assumes that anything in the VIPC should get installed into the virtual environment -- this is an area of use case and feature investigation.

Would you want to be able to specify in Dragon that specific packages should be installed globally vs in the lv-venv? Ideally, the user should not need to worry about such things, yet at the moment it is a consideration the user must make.

[Display list of missing required packages]

@kosist @Mariano Aristu

Here is a possible solution:

Please let us know if you have any other suggestions.

Note: it will usually/ideally show the package's Display Name (instead of file_name).

[Display list of missing required packages]

8 hours ago, Mariano Aristu said:

It will be great to know also where is going to be installed (lv-env or general)

Yes, that would be great to know, too!

[Separate packages which could work not properly while being installed in lv-venv folder]

There are some really great ideas and observations in your post @kosist.

Yes, this is something that we're thinking about and working on. In an ideal world, a user would activate a virtual environment and all the LabVIEW IDE extensions installed into the virtual environment would show up in the IDE.

There are a variety of possible solutions and I think that none of them are 100% complete, due to the fact that LabVIEW extensions (right-click menus, project providers, tools menu) must be installed globally (based on how LabVIEW presently works).

In the short term, I think that allowing flexibility to users (that allows installing into both the global and/or virtual environment) while at the same time providing some visibility and warnings around possible problems/conflicts will be most helpful as we figure out more automated/ideal solutions.

[Installing global package while it depends on the package installed locally could lead to VIs conflict]

Thanks for the great post with detailed steps to reproduce!

I have a few thoughts about the situation you described:

Dragon Should Probably Not Allow Installing Packages into Both Global and Virtual Environments

First, I generally think Dragon should move in the direction of not allowing a package to be installed globally AND in the virtual environment, due to the conflicts and cross-linking that can happen. Right now, Dragon is allowing that in order to have flexibility until we work out all the details and more fully understand the various use cases.

Caraya Should Probably Build JKI SM Into Itself (not expose it as a dependency to users)

Second, I would like for Caraya to not depend on the JKI State Machine (so, perhaps it should build in the JKI State Machine as an internal dependency and not expose it to users) -- it's such a core utility, it's not actually a library that gets built into the end-user's distributable application, and it's probably better not to expose users to a dependency constraint.  All that is to say: "Maybe eventually Caraya shouldn't require installing the JKI State Machine, so part of this problem might go away"

Libraries and IDE Extensions Should Probably Be Split onto Separate Packages

As you pointed out in this other topic, the JKI State Machine may eventually be split into two packages: One that contains the library code that the user will call directly in their applications (which will naturally be best installed into the lv-venv) and another that contains the LabVIEW IDE extensions: right-click menus, etc. (which will need to be installed globally).  This eventuality we're considering doesn't directly follow from the example you posted about Caraya, yet I figured it was worth mentioning and we're giving it a bit of thought right now.  This would possibly require package developers to be more aware of virtual environments and the need to split a package into two parts -- and, it would be nice if VIPM's package builder and/or VIPM/Dragon could help do this automatically. Again, we're thinking about the best ways to do this.

Try Installing Caraya into the Virtual Environment

It might be a good idea to install Caraya into your virtual environment. I think there may be a few quirks that don't work great like the Tools menu options, but for the most part, I think Caraya works well when installed into the lv-venv.

[Dragon Welcome screen, right-click on empty space -> Open -> Cancel -> displays empty window]

Good catch. We'll have this fixed in the next build (>=2715)

[Issue with package list populating with VIPM 2020]

That's strange. I wonder if there's some kind of permission issue.  Does "Everyone" have Full Control on the "C:\ProgramData\JKI\VIPM" folder?

[Issue with package list populating with VIPM 2020]

Hi Peter,

Can you try exiting VIPM, deleting the cache folder, and then restarting?

C:\ProgramData\JKI\VIPM\cache

 

[Unpublished ESF toolkit can not be installed in lv-venv]

Hi @kosist

Thanks for that information.

Can you tell me more about the exact steps you might have used when the error showed up?

First you said "Install ESF toolkit globally" then "Try to install ESF toolkit from Dragon window, by right-click on the toolkit in the list".

What did you right-click on to try install it into the virtual environment? Did you add it to a VI Package Configuration, uninstall globally, then try to install it locally?

Any specific steps would be very helpful.

Thanks!

[Feature Guide: Working with Multiple LabVIEW Project Files (e.g. RT, FPGA, Host)]

yes, that's right -- the .dragon file can be placed in the very top level folder of the project source code and the .lvproj, .vipc, and .vipb files can be kept in subdirectories. There's a new feature in the latest build that helps with this, too.  When you're opening a new project for the first time, Dragon will search in subfolders (up to two levels deep) for these .lvproj, .vipc, and .vipb files when it auto-populates the dragon project configuration for the first time.

[When Dragon points to non-existing VIPC file, no packages are shown (global/local)]

Good catch! I agree that a missing .vipc file should not cause Resources package lists to be empty. We'll fix that...

[Display list of missing required packages]

That's a really good point -- a user probably doesn't feel 100% comfortable agreeing to installing all the packages until they know what packages will be installed.

[Issue with package list populating with VIPM 2020]

Hmmm... which "list" are you referring to? The main VIPM package list or the Dragon project's Resources tree/list of packages?

Also, can you look in the "C:\ProgramData\JKI\VIPM\error" folder to see if there's any error messages logged?

[Manual editing of LabVIEW version]

Hi @kosist. Thanks for sharing your observations about this. Here's what's going on.

Currently, there is not much validation of the LabVIEW Version requirement. Eventually, there will be more validation and user feedback.

A.) For projects that use a virtual environment, the LabVIEW version in the virtual environment is used for determining which LabVIEW version to use for editing the project.

B.) For projects without a virtual environment, the LabVIEW Version of the dragon project configuration is used for determining which LabVIEW version to use for editing the project.

C.) Also, when creating a new virtual environment, the LabVIEW Version of the dragon project configuration is used for determining which LabVIEW version to use for creating the virtual environment (goto "A").

As such, if a project has a virtual environment, then the LabVIEW Version in the configuration is somewhat ignored, currently.  In the future, we'll add more enforcement and checking of this, when it is changed by the user or if it ever differs from the virtual environment.

[Text cut on the VIPM - Working dialog during Extensions installation]

There's a new build of dragon that fixes this issue with the Please Wait dialog text cut off. Download it here.

[VI Package Builder reports "friends" (community scope) as missing]

There's a new build of dragon that fixes this issue and allows packages with Friend Classes to build correctly. Download it here.

[Feature Request: Multi-Select in Dragon]

There's a new build of dragon with Multi-Select in the tree. Download it here.

 

[How to Install Instrument Drivers (in virtual environment folder)]

There's a new build of dragon that now correctly shows palettes for Instrument Drivers, User Libraries, and Add-ons correctly. Download it here.

 

 

[New Dragon Build (2712) Available for Download]

There's a new build of Dragon and VIPM 2021 Beta: Download it here

Here's what's new:

• Improved Palettes for Virtual Environments - Virtual Environment Palette now show Instrument Drivers, User Libraries, and Add-ons correctly (reported here)
• Multi-select - Select and operate on multiple items/packages in the Resources tree-view to allow install/uninstall multiple packages at once (reported here)
• Improved New Project Configuration Detection - new project dialog will now search in subfolders (2 levels deep) for the .lvproj, .vipc, and .vipb file -- this is helpful if the root folder of the project does not contain these project files, and they are located in subfolder.
• Missing Friend Classes No Longer Cause Package Build Errors -  The package builder was raising a dependency missing error if a friend class could not be found. However, friends are not actually required. Now they don't cause a missing dependencies error (reported here)
• Improved "Please Wait" Dialog - Fixed text cut off in the Please Wait Dialog (reported here)

Here are more details for a few of the new improvements:

Improved Palettes for Virtual Environments

Virtual Environment Palette now show Instrument Drivers, User Libraries, and Add-ons correctly.

Multi-Select

You can Ctrl+Click or Shift-Click to select multiple items in the tree. Right-click actions apply to all selected items, as you can see in the animated screetshot below.

Improved New Project Configuration Detection

The new project dialog will now search in subfolders (2 levels deep) for the .lvproj, .vipc, and .vipb file -- this is helpful if the root folder of the project does not contain these project files, and they are located in subfolder.

 

[Understanding Interactions between Global and Virtual Env Package Dependencies]

Hi Steven,

LabVIEW plug-ins launched via quickdrop, right-click, project providers, tools menu, etc, typically get run in a different application instance and thus have their own VI namespace — each application instance can have VIs in memory with the same name, but loaded from different locations on disk.

I hope that helps.

[Feature Request: Multi-Select in Dragon]

Great idea, @Steven Dusing!

We're working on this and it should be available in the next build.

[Need a Better Way to Interact With Dependencies (Allow package information window to be default or floating)]

This is really great feedback @Ryan Good.

First, I agree that the Package Properties window gets in the way when trying to use it to manage dependencies, due to its modal nature.

Also, I agree with you that there are use cases for installing some packages globally -- in fact, some packages really need to be installed globally to fully work (right-click extensions, project providers, etc).

And, it would be nice to be able to manage/visual dependencies easier.

Here's a summary of what I think the use cases are:

- It would be nice to be able to specify if a package should be installed globally or into the lv-venv.

- It would be nice to more easily add package dependencies (and sub-dependencies) to a project configuration

- It would be nice to more easily see/know a package's dependency information -- know whether a dependency is a direct/primary dependency or a dependency of a dependency (indirect/secondary/tertiary).

Does that cover the use cases for this? Can you think of others or a need to further clarify any of the above?

[Palette not found/shown (maybe due to folder structure?)]

Thanks for reporting this @Joerg Hampel. Yes, there is currently a problem with this feature -- we're working on it.

[VIPM 2020 doesn't start]

Hi @Yann. Thank you for sharing how IT resolved the issue for you. That's really helpful to know.