proposal Should OpenG Move to vi.lib?

[asbo]

Definitely don't do the move piecemeal - all or nothing. If you want to trial it, make better versions available for brave adventurers to try on their own.

[crelf]

Doing things right from the beginning (or as soon as possible for retroactive situations) ALWAYS pays off in the long run. If not then we all ought to just be jusing shifts and FGVs, typedef clusters....

[jgcode]

So, to summarize, the majority of users would support this move (and that we would do it atomically all in one release avialable at the same time)?

[gb119]

(and that we would do it atomically all in one release avialable at the same time)

And with a bump in the major version of all packages please so that it's really obvious when it's happened....

[Aristos Queue]

You're going to be forcing a relink of any existing VIs that expect to find their subVIs in user.lib but now find them in vi.lib. That's going to be a source-code level change for caller VIs (updating their saved subVI paths). It also means anyone loading any of these VIs dynamically needs to update their code. This is, in many ways, a change that breaks backward compatibility.

Does VIPM give you any way to give feedback to users about the effects of a particular upgrade at the time that they choose to upgrade? If so, you probably want to employ that mechanism.

Given that, I can imagine some people wanting to have both the user.lib and the vi.lib versions installed on the same LabVIEW. You could choose to not call this an upgrade but instead issue brand new packages, deprecating the ones in user.lib. That way people don't see these new versions as "upgrades" but actual new tools, which they would only adopt for new projects, and might continue to use the existing user.lib packages for existing projects.

[jgcode]

Great points, thanks for the feedback.

It also means anyone loading any of these VIs dynamically needs to update their code. This is, in many ways, a change that breaks backward compatibility.

If the user linked to the VIs correctly this will not be an issue (i.e. will not break any code).

There is a OpenG VI that defines the OpenG directory.

Therefore, for this move it is noted that:

• The OpenG Library VI will need to be updated
  
• Underlying sub folder structure will not change
  

You're going to be forcing a relink of any existing VIs that expect to find their subVIs in user.lib but now find them in vi.lib. That's going to be a source-code level change for caller VIs (updating their saved subVI paths).

This should be ok? Given that the user chooses to upgrade to the newer version, they will need to except that a recompile will be required. LabVIEW should handle this automatically (as reported earlier from my testing). However, we could even provide a VI to be downloaded that is an OpenG VI Tree containing all OpenG VIs so the user could open it first, then open their project code. The VI Tree will have the OpenG VIs in memory and LabVIEW will link to these on opening the user's code. (then they just do a save).

Does VIPM give you any way to give feedback to users about the effects of a particular upgrade at the time that they choose to upgrade? If so, you probably want to employ that mechanism.

Yes, we have been using that feature since switching to VIPM and will continue to do so.

As mentioned above, this would also be a major release e.g. v5).

Given that, I can imagine some people wanting to have both the user.lib and the vi.lib versions installed on the same LabVIEW. You could choose to not call this an upgrade but instead issue brand new packages, deprecating the ones in user.lib. That way people don't see these new versions as "upgrades" but actual new tools, which they would only adopt for new projects, and might continue to use the existing user.lib packages for existing projects.

I (personally) cannot think of a reason users would have both installed?

So I am thinking upgrades would be preferable for this.

[lvb]

Just wanted to chime in that I support the move. It should be all at once with a bump in the version number. Given the nature of the change, does it justify a "major" version increment?

[jgcode]

Given the nature of the change, does it justify a "major" version increment?

I would think most definitely (this is just my personal opinion at the moment).

[Val Brown]

Just wanted to chime in that I support the move. It should be all at once with a bump in the version number. Given the nature of the change, does it justify a "major" version increment?

I would think most definitely.

Yes definitely it's a major release with a significant change like this -- which is being handled very well IMHO given all that you've said.

[jgcode]

which is being handled very well IMHO given all that you've said.

The OpenG Board will make the final decision on changes related to the direction of OpenG, but by all means, everyone's opinions, ideas and feedback are very much welcome and respected - so please keep them coming.

[GregSands]

Yes definitely it's a major release with a significant change like this -- which is being handled very well IMHO given all that you've said.

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

[jgcode]

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

Please keep this thread on topic.

But, by all means, create a new thread to discuss new ideas (other than moving to vi.lib)!!

In this case, this thread already exists here: Migration of OpenG Projects to LabVIEW Project Libraries?

Cheers

-JG

[Ton Plomp]

I was just building a tool and wanted to include OpenG as sub-vis of the tool.

And that is possible, I can uncheck the 'exclude files from user.lib' to achieve that.

However if we move OpenG to vi.lib we cannot use the 'exclude files from vi.lib'. Since that would include a lot of internal vi.lib stuff...

So in a blink of a second I changed from 'YES' to 'NO'

[Jim Kring]

I was just building a tool and wanted to include OpenG as sub-vis of the tool.

And that is possible, I can uncheck the 'exclude files from user.lib' to achieve that.

However if we move OpenG to vi.lib we cannot use the 'exclude files from vi.lib'. Since that would include a lot of internal vi.lib stuff...

So in a blink of a second I changed from 'YES' to 'NO'

Ton: Can you explain more about your use case? For example, the type of tool you are building, what you're using to build your tool (OpenG Builder, LabVIEW Application Builder), and why you need to exclude OpenG but include other vi.lib stuff?

[Ton Plomp]

I'm currently using NI Source distribution builder together with VIPM to create a LVTN version of the Code Capture Tool.

One of our (mine and Yair) targets is to be independent on other tools like OpenG (however when using VIPM that is very unlikely).

So I made a source distro with LabVIEW, and included any stuff in user.lib (OpenG) and excluded vi.lib.

Just for fun I embedded vi.lib, and the support folder went from 500 kb (OpenG) to 2.8 MB (including all the config files for instance).

Ton

[jgcode]

And that is possible, I can uncheck the 'exclude files from user.lib' to achieve that.

FWIW, I also commented on this previously here

[Jim Kring]

I'm currently using NI Source distribution builder together with VIPM to create a LVTN version of the Code Capture Tool.

One of our (mine and Yair) targets is to be independent on other tools like OpenG (however when using VIPM that is very unlikely).

So I made a source distro with LabVIEW, and included any stuff in user.lib (OpenG) and excluded vi.lib.

Just for fun I embedded vi.lib, and the support folder went from 500 kb (OpenG) to 2.8 MB (including all the config files for instance).

Ton

Have you tried building your Code Capture Tool using VIPM's package builder? It excludes stuff in vi.lib and has the option to include or exclude individual OpenG packages.

[gb119]

Have you tried building your Code Capture Tool using VIPM's package builder? It excludes stuff in vi.lib and has the option to include or exclude individual OpenG packages.

Ummmm I get this funny feeling of a conversation going in circles here....

What order does the general policy (e.g. exclude vi.lib) and the package specific rules (e.g. but include OpenG packages) get applied in ? If the individual package (in|ex)clusions are taken after the blanket vi.lib rules then it sounds like Ton should be able to build his package even if OpenG were to move to vi.lib (assuming also that the package specific rule handled dependencies, so that if include the OpenG meta package in my build it includes all of the vis in all of the OpenG packages...).

[jgcode]

Ummmm I get this funny feeling of a conversation going in circles here....

What order does the general policy (e.g. exclude vi.lib) and the package specific rules (e.g. but include OpenG packages) get applied in ? If the individual package (in|ex)clusions are taken after the blanket vi.lib rules then it sounds like Ton should be able to build his package even if OpenG were to move to vi.lib (assuming also that the package specific rule handled dependencies, so that if include the OpenG meta package in my build it includes all of the vis in all of the OpenG packages...).

There are two build processes being discussed here: LabVIEW Builder and VIPM. They should not be confused with each other.

[lordsathish]

Now, on the flip side, NI might decide to move vi.lib out of Program Files under such a scenario. There's lots of possibilities here. So, it's not necessarily a showstopper, but I'd suggest you investigate MS' Windows 8 plans before deciding this issue.

Does NI has plans to move vi.lib to ProgramData ? This seems to be a likely plan for NI. If addons have to be installed into vi.lib, it should be outside Programfiles for other applications to have access. Then there is a possibility that user.lib is separate for each user and is moved to AppData of each user. If Addons go into user.lib that is different for each user, that doesn't make sense. That could be the reason why NI is recommending Addons to be moved into vi.lib

I'm making lot of guess. Someone should comment on what part of it is really possible.