Open Package Building Discussion

[Michael Aivaliotis]

8 hours ago, ShaunR said:

That's not my vision and would argue that it would be no better than under vi.lib. I think we both see the value of install but for uninstall you don't want to touch the target packages - just delete or recreate the links.

I get that. But thinking about it even more. It seems you would want to have a feature to completely remove an installed Package ?. Otherwise you would have an ever-expanding database of files.

[ShaunR]

On 11/1/2018 at 8:59 AM, Rolf Kalbermatter said:

If there are specific situations where someone wants to discuss a different license for whatever reason with me for any of these libraries, I'm willing to discuss that. But as a community submission it will remain as it is for the foreseeable future.

I've resolved the issue.

Zlib Library for LabVIEW (BSD-3)

[ShaunR]

Getting back to this again.

What should we do with plain zip files?

What I'm thinking of are the zip packages which are basically "install to a place of your choice-have fun" type packages. Many of these are given away as "driver" packages for interfacing to hardware.

OGPM, VIPM and NIPM all have meta data of how and where to install but a simple zip file has no meta data.

How would we handle this? Should we handle this?

[Rolf Kalbermatter]

I would tend to say that it is overkill. If you really want to handle this it coudn't really be more than a 1:1 copy of the complete content to the user selected destination directory. Personally I find that this is easier to handle in 7-zip or similar on windowed desktops and on the command line if you work predominantly there (though why would you use LabVIEW then 😀).

[ShaunR]

15 minutes ago, Rolf Kalbermatter said:

I would tend to say that it is overkill. If you really want to handle this it coudn't really be more than a 1:1 copy of the complete content to the user selected destination directory. Personally I find that this is easier to handle in 7-zip or similar on windowed desktops and on the command line if you work predominantly there (though why would you use LabVIEW then 😀).

Well. You could also generate a menu so it appears in the palette.

[Rolf Kalbermatter]

If you install it in instr.lib or user.lib and do a menu refresh (application property node) it should be added anyways although with a default icon but what else would you want to add there? Creating a nicer default icon?

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

If you install it in instr.lib or user.lib and do a menu refresh (application property node) it should be added anyways although with a default icon but what else would you want to add there? Creating a nicer default icon?

True. I'm just spit-balling.

You may also get version control out of it.

[ShaunR]

 What should the source code minimum version be? By that I mean the source code of the package manager itself, as it would ideally be open source.

Obviously 2009 is my preference but that requires 3rd party toolkits for HTTP and HTTPS; which is not really tenable for most people. Later versions are plagued by stability and performance issues so I guess what I'm asking is what is the minimum stable version of LabVIEW that should be supported based on prevalence.

 

 

 

 

 

 

[smithd]

2013 is my go-to for stable+old. 2010+11 had the new compiler, 12...I dunno what happened with 12, but it sure seemed to be unstable. Its probably a lie that my brain made up, but it always seems like the even years are much worse than the odd years, with the exception being that 2018 seems pretty solid.

2013 has the new compiler (2010) with the performance issues resolved (2012), auto-concatenating terminals (2012), somewhat improved web service scheme, get class instance by name, dotnet CLR got bumped to 4.0 (I know this may be a negative to you ). The only big issue I know of is the attached code comment arrow thing, which results in an instacrash at a later date if you duplicate any multi-frame structure that has one inside.

You miss out on custom right click menus (2015), VIMs and read-only DVRs (2017), and the CLI, python node, and type disable structure (2018) -- of these only the custom right click menu is probably helpful.

Edited February 19, 2019 by smithd

[drjdpowell]

I also use 2013 as my base for most reuse packages.  It has the new tunnel options including the valuable "conditional" (fixed over 2012 to have good performance) and Variant Type VIs that are about 100 times faster (than in 2011 at least).  The next really useful feature is VIMs in 2017.

[ShaunR]

On 2/19/2019 at 6:54 AM, smithd said:

dotnet CLR got bumped to 4.0 (I know this may be a negative to you )

I don't care what version of .NET is required. All .NET is banned from my projects and some of my hair has grown back as a result 

I too have products in 2013 and have found it relatively stable. It was my next choice if I were to be dragged kicking and screaming from 2009 

Anyone else prefer an earlier version than 2013?

Edited February 20, 2019 by ShaunR

[Mads]

Having lots of connection issues with VIPM (turned out to be an issue with the JKI server certificate I found out on my own...), I just had a relook at G Package Manager...

Is it seriously based on people having to use the command line to install packages?🤦‍♂️ The main selling point of LabVIEW is that it is *graphical*....and it is trying to force everyone to use the command line??

At least then integrate it into Windows Explorer so that I can right-click my project folder and choose packages to install then and there. O rhave a graphical browser that displays the pacakges, and let me choose a bunch of them there and then point them to the project directory for one batch install. Installing one package at the time is terrible - it would mean that I would need to install 10-20 packages in every project. If so, make it possible to make package groups at least, so that we can install a bunch of the usual suspects with one click.

*Ideally* you would have the packages installed in your user.lib or somewhere else centralized instead, and then if you use anything from any of the packages, they are automatically copied into the project...(yes, this is one of the few places where NXG might be on the right track...).

[Michael Aivaliotis]

On 6/23/2020 at 7:24 AM, Mads said:

Is it seriously based on people having to use the command line to install packages?🤦‍♂️ The main selling point of LabVIEW is that it is *graphical*....and it is trying to force everyone to use the command line??

I know there is a GUI for it, I've seen it. But the marketing for it, does not promote it anywhere. I wish I could quickly point to where that is, but unless it's accessible from the homepage, you lost me. If you take the philosophy that GUIs are not for real programmers, then you will start to align with GPMs design language.

[Mads]

9 hours ago, Michael Aivaliotis said:

I know there is a GUI for it, I've seen it. But the marketing for it, does not promote it anywhere. I wish I could quickly point to where that is, but unless it's accessible from the homepage, you lost me. If you take the philosophy that GUIs are not for real programmers, then you will start to align with GPMs design language.

Sounds like a philosophy not exactly aligned with using LabVIEW...

I found it now though, it is called the GPM Browser. Re-reading the documentation I noticed a sentence about it that I had overlooked.

It is not marketed much though no, you have to RTFM 🙁