Allow <project> as a Search Path

[James_McN]

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.

[joerg.hampel]

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 🙂

[AristosQueue (NI)]

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]

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.

[joerg.hampel]

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?

[DerrickB]

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]

This should be the easiest IDEA  ever

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

But, kudos 

[Chris_Cilino]

Howdy ya'll

I'm not quite sure but this may be a duplicate of https://forums.ni.com/t5/NI-Package-Management-Idea/Per-Project-Virtual-Environments/idi-p/3969147?p...

What do you think?

[James_McN]

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!

[Chris_Cilino]

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.