Per Project Virtual Environments

[Chris_Cilino]

If you haven't seen it, GPackage (https://gpackage.io) manager is a new package manager that has a tremendous amount of promise. It offers the ability to install different versions of the same package simultaneously to a version of LabVIEW. This allows the creation of "sandboxes" where on a per project basis I can tightly control which version of software I'm using. Another way of saying it, I can prevent the upgrading one version of a library from having unintended effects across different projects. 

I would love to see NI package manager \ LabVIEW support a per project "virtual environment". I could see this being accomplished by creating a per project user.lib and instr.lib. But that's just one idea...

I highly recommend NI examine, in detail, G Package manager and incorporate its per project capabilities into LabVIEW and NI Package manager. The ability to install multiple versions of the same package on a per project basis solves quite a few problems. That having been said we would also need the ability to install one package globally and resolve conflicts between the per project and global versions of a library.

FYI: please be aware of the labviewwiki.org article comparing the three different package managers:

https://labviewwiki.org/wiki/Package_Manager_Comparison

[jon_mcbee]

+1 for GPM functionality.  What is the use case for global packages?  Would these be more in the context of IDE extensions than reusable components for application development?  I guess a better question would be what situation would cause a conflict between a globally installed package and a locally installed package?

[Chris_Cilino]

@jon_mcbee

Good question. Here's the scenario I can think of maybe...

"I'm a user" who want to use package version X across all of my projects. I prefer simplicity and don't want to have to manage lots of versions of a package. That's just a headache! I mean I "work with LabVIEW" and don't want to be bothered about much else. Too much time wasted on "versions" and not enough time spent on solving the problem. But... In the case where I might want some feature in a new version, I'd like to test that new feature out in the context of a new project. So I want to override the global version and use this per project version. Then if the new version "passes muster", I'll make that my new global version. 

Of course that's just one of many types of personas each with their own sets of workflows.

[pawhan11]

If only LV could work like Python virtual environments... 

Each project could have separte space with all packages it requires and all continious integration processes would be much silmper 🙂

[malocascio]

Agreed, and like @pawhan11 said, python virtual environments are a great model for this. Not just for package management, but for associating specific virtual environments with specific LabVIEW versions, and for customizing the development environment to the needs of that project.

[Taylor.Kendall]

The workarounds that we had to build to accommodate this have been an absolute nightmare to implement, but once they were working were great.  Our big complaint is that we would like to be able to change the palette depending on the project we are working on.  Basically the only thing we were unable to do. 

Out system is made up of SVN externals/git subrepos, halfway between a python environment and a visual studio solution. 

[Chris_Cilino]

cross linking to another idea that is almost identical here:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-lt-project-gt-as-a-Search-Path/idi-p/4053815

Allow <project> as a Search Path 

by James_McN