VIPM is terrible

[cirrusio]

So, I have never been terribly successful with VIPM - seems like a needed tool but the errors that it throws are not decipherable much of the time. As such, I have the following problem:

I have a set of objects in 2016 that I want to convert to a user library.  I want to preserve the disk hierarchy as they will be referenced by other libraries with that expect a particular location. As such on the Destination  tab, I select Destination Type -> Directory (Preserving Heirarchy).  Unfortunately, when it is building the library, it throws the error 1357 as shown below:

What this error seems to be suggesting is that it already has a VI located in the directory ..\Session APIs with the same name.  But, this is not preserving the disk hierarchy.  This particular VI is located in reusable\Session APIs\File Access\Config Data. So, what's the deal??  This is of course going to cause lots of conflicts if all VIs are dumped into the same directory as the method in question is a superclass method.  Why is it doing this?

I so want to like this tool, but I keep getting jammed by stuff like this.

[tyk007]

I've built a lot of components using VIPM (some fairly substantial) and not had an issue like this. I've also never had the project open during a build though I suspect that VIPM will be loading them into a unique application instance.

The VIPM forums might be a better place to ask: http://forums.jki.net/forum/5-vi-package-manager-vipm/. You might get more specific responses.

[cirrusio]

Ugh...and herein lies the problem with no native package manager - I have no real interest in using yet another forum platform.  So, as an update - I have tried building with everything initially closed to no avail.  I have also tried mass compiling the folder that appears to be generating the problem, also to no avail.

[billko]

I just let the package build and distribute to vi.lib where it wants to go.  Since vi.lib is also in the default search path, I've found that if you delete the original library from user.lib, all your projects will find them in vi.lib instead.  Even if you don't keep the same hierarchy, LV does a pretty good job at figuring out where everything went.  If you do keep the same hierarchy, it usually involves zero user interaction to load from the new path.

I've also gotten out of the habit of placing my source library code in user.lib because it is no longer the working code.  Those projects now reside in my LabVIEW Projects folder.  This keeps VIPM from getting confused.

I hope this helps.

[tyk007]

---

@cirrusio wrote:

Ugh...and herein lies the problem with no native package manager - I have no real interest in using yet another forum platform.  So, as an update - I have tried building with everything initially closed to no avail.  I have also tried mass compiling the folder that appears to be generating the problem, also to no avail.

---

You could also share the source that is giving you trouble to give someone else an opportunity to replicate your issue, rule out installation problems. I don't understand your hesitation to go the best place to find help but each to their own.

[Hooovahh]

Sorry you find it terrible, I do not, I use VIPM pretty extensively and have issues with it, but it generally gets the job done.  I do agree that VIPM's errors are a bit cryptic, and when they happen I'm usually stuck with a trial and error until things start working again.  I've only used Preserving Hierarchy on all the packages I've built, and generally I add a short suffix or prefix to all VIs in the package to help with naming collisions with the source.  As others have said if you can share more of what doesn't work maybe we can help troubleshoot it.  The VIPM forums are probably a better place for this (sorry for so many dis-conjoined forums) but plenty of us on the NI forums use VIPM often enough that we can help.

[soupy]

I agree that VIPM is the worst LabVIEW package manager, but it is the only one so it is also the best (-:

I've had many build issues as well with some quite large libraries. The cryptic errors are always not very helpful... My go-to fix is to first build all the source files into a source distribution with a common top folder and then build the package from that folder. This seems to fix pathing issues in VIPM and generally make it happy. I understand that this is an extra step, but in my experience this extra step takes less time than troubleshooting a failed build.

Hope this helps!

[cirrusio · Accepted solution]

Well...as it turns out, probably most of my problems stem from my porting from 2014 to 2016 (and as it turns out, a package that I use extensively that is deployed to user.lib - had no idea that LV would not search these libraries for missing VIs).  

That being said, I am still trying to build packages and running through all of the errors which takes a lot of time due to the lack of information provided by the error handler.

VIPM is likely a reasonable tool (my title is intended to catch eyes and doesn't necessarily reflect the state), but after using other package managers in other languages, I just can't help that this tool is doing a little too much (and that there should be a native package manager).  Anyways, that is for another thread.  

Thanks, all

PS - As a veteran of this and other coding communities, I understand that posting code would likely provide further insight for those answering questions, but I have always felt these to be bothersome comments.  Most people who can post code likely would while others of us don't simply because the code base is often too large or the deployment directives just a bit too complex sometimes leading down a rabbit hole of bad conclusions and wasted time for all.

[billko]

---

@cirrusio wrote:

Well...as it turns out, probably most of my problems stem from my porting from 2014 to 2016 (and as it turns out, a package that I use extensively that is deployed to user.lib - had no idea that LV would not search these libraries for missing VIs).  

That being said, I am still trying to build packages and running through all of the errors which takes a lot of time due to the lack of information provided by the error handler.

VIPM is likely a reasonable tool (my title is intended to catch eyes and doesn't necessarily reflect the state), but after using other package managers in other languages, I just can't help that this tool is doing a little too much (and that there should be a native package manager).  Anyways, that is for another thread.  

Thanks, all

PS - As a veteran of this and other coding communities, I understand that posting code would likely provide further insight for those answering questions, but I have always felt these to be bothersome comments.  Most people who can post code likely would while others of us don't simply because the code base is often too large or the deployment directives just a bit too complex sometimes leading down a rabbit hole of bad conclusions and wasted time for all.

---

You're forgetting one thing.  Not everyone is a veteran.  Most often, a prompt to post code is a timely one and expedites a solution.

[cirrusio]

---

@billko wrote:

---

---

You're forgetting one thing.  Not everyone is a veteran.  Most often, a prompt to post code is a timely one and expedites a solution.

---

Not forgetting - just reminding others that sometimes (many times) posting code is not an option.  In this instance, I just wanted some insight into what the error meant and code was not really necessary.  As it turns out, this answer is probably sufficient - "Error codes generated by VIPM are uninformative at best.  Good luck!"