Leaderboard

Hey, Derek here. Stoked to see GPM came up. Couple of things I want to mention. The current GPM release is still a beta release. If you find bugs or want to request features, add them to the issue tracker. https://gitlab.com/mgi/gpm/gpm @ShaunR Theres a CLI and a GUI. The CLI will probably be used by CI setups, the GUI will be used by people. Eventually (though not currently) anything that you can do in one you can do in the other.(the "commands" that the CLI and GUI execute are just two different ways of executing the exact same business logic.) I know it needs to support distributing things like quickdrop plugins. I haven't quite decided how I'd like to do it, but I definitely realize it's something that's needed before a full on release. https://gitlab.com/mgi/gpm/gpm/issues/18 Yeah, @David_L I agree, +1 to the number of package managers sucks. Sorry :/ Back to the OP's topic: One of GPM's goals was to answer this question. If you have code that you want to give out for free, I think it should be trivially easy to do so. Using GPM, you just fill out the meta data, create an account on https://gpackage.io/ and then click publish. Once the command has finished executing you're good to go. It's published on the internet so anyone can download it. Someone who wants to use your code just needs to install it using GPM. If your code depends on other packages they'll be installed at the same time. It should be super easy (let me know if it's not!) Additionally, GPM package meta data has all of the fields needed to properly index your stuff and link back to your repo. This makes it easy for people to find your code, and contribute to it as needed. Happy to answer any more questions (or argue about design decisions =P)

Possibly. This is why "Real men run as root" Anyhoo. I think any attempt to create a [universal] builder/installer would be best envisaged on Windows first to prove the concept, so these kinds of quirks could be ironed out later. The success of such an endeavour would (I think) be very dependant on symlinks as they are kind of like a silver bullet to allowing different library versions and LabVIEW versions of the libraries to exist side-by-side and swap between. The conclusion I came to with my investigation was that a separate repository (in "Program Data") of installed toolkits, under each LabVIEW and toolkit version, enabled very quick and easy uninstall and version change by simply creating and deleting symlinks in the vi.lib directory pointing to them. Once that is achieved, then project based installs become a simple matter of choosing which links are present for each project whilst still maintaining menus in the palettes.