LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

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
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 🙂


An opportunity to learn from experienced developers / entrepreneurs (Fab, Steve and Brian amongst them):
DSH Pragmatic Software Development Workshops

Automate the testing, documenting, building, packaging and publishing of your projects via CI/CD:
Release Automation Tools for LabVIEW

Proven Zealot

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?

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
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?


An opportunity to learn from experienced developers / entrepreneurs (Fab, Steve and Brian amongst them):
DSH Pragmatic Software Development Workshops

Automate the testing, documenting, building, packaging and publishing of your projects via CI/CD:
Release Automation Tools for LabVIEW

Member

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.

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
Active Participant
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
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.