LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
James_McN

Allow <project> as a Search Path

Status: New

In LabVIEW we can specify <topvi> as a VI search path when VIs can't be found.

 

I would propose adding <project> as an option (perhaps with a subfolder by default). This would allow for new reuse patterns based on keeping libraries in the project. I expect this would make tools like GPM much easier to develop as well.

 

It could be a first step to something like node_modules in NPM or virtual environments in Python.

 

James_McN_0-1590488521270.png

 

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
9 Comments
joerg.hampel
Active Participant

Yes, please! Coming from a great conversation between James McN, Darren.M,  Chris.R, Richard.T and myself on our ALA Slack channel, it would be even greater if that conversation led to this feature being implemented 🙂




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


AristosQueue (NI)
NI Employee (retired)

I proposed something like this in the past and got push back because then it would make the same subVI find different things depending upon how it was opened -- was it opened within a project or not. It would make for inconsistent mass compile results. I was ok with that behavior, but I was the minority opinion in the room. It was just a small group discussion when we were trying to figure out how to improve crosslinking back in the LV2010 timeframe, so it's never been out for larger discussion, so far as I know.

 

How do you all feel about that difference in mass compile behavior?

James_McN
Active Participant

I knew there would be some interesting cases to be handled.

 

I'm not so worried about the difference based on where it is opened. That is the entire benefit. With CI and team-based development, we already have this case when the code is moved to another system and dependencies are out of sync.

 

If I understand correctly mass-compile doesn't use the project context so you could have the VI open in the project, run mass-compile where it would compile without the project context. This could fail if something is required from the project. Then if you force-compile the VI with the run arrow it would build again.

 

I do see the concern with this and it would probably need addressing somehow. For me personally, I could cope with this I think for the benefits of having a project search path.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
joerg.hampel
Active Participant

I agree with James, having that different behaviour depending on from where it's opened would be the actual benefit. I would very much appreciate that option.


Yes, it needs to be handled in a way that doesn't make life harder for the average use(r). Maybe it could be an optional, per-VI setting that's visualised very prominently?




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


DerrickB
NI Employee (retired)

I wouldn't be upset at being required to always work within a project which may ease a few of the hurdles.

 

Perhaps this could be a per project / per library stored config? Moving VIs around on disk would already break linking for those that don't have search paths set so I find it unlikely to cause upsets for this to be catered to the kinds of people that dig into the search paths property and produce some different results if extra configs are available. Then the environment isn't changed and default behavior isn't affected but some people could start setting extra options (perhaps even as build steps?) to enable some much needed packaging features.

JÞB
Knight of NI

This should be the easiest IDEA  ever

 

Didn't you ever open a project in a text editor???

 

But, kudos 


"Should be" isn't "Is" -Jay
Chris_Cilino
Active Participant
James_McN
Active Participant

Definitely same end goal - this is intended to be lower level so any package manager could use it (or spin your own management system) so I would say they are related but different.

 

I've kudosed yours as well though!

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
Chris_Cilino
Active Participant

Very cool. Thanks James! I've posted a link to this thread in the other idea exchange so that the two efforts can be linked.