Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by RocketHacker

  1. I've built a custom package and set it as incompatible with a 3rd party package. VIPM doesn't recognize the conflict on installation of my package, but acknowledges the conflict via icon after the install. clicking the icon and selecting "Install missing dependencies" just gives a dialog saying "There is nothing to do. All the packages are already installed". If I were not he original author of my package i would be very confused what was going on here... running VIPM 2016.0.0.1986 Of course the manual workaround is to manual uninstall the conflicting package, but i'm trying to get a solution that automatically does this. just looking to file this as a bug report.
  2. brilliant! I'll look into my failed builds to see if i'm hitting the same issue. thanks!
  3. i've ran across this and never was able to distill it down to a root cause. i know that it has something to do with having dependencies outside of the package source folder. i was able to successfully work around it by: create project for source files put source files into that project build source distribution of source filesadd source files to always included section in source file settings, put dependencies in support directory. apply name prefix to prevent name spacing issues later [*]build vi package from source distribution this sucks because it adds an extra step. i was annoyed by this until i realized that i had wasted about 20 hours trying to get it to work initially. the extra 5 min to do the source distribution is way less painful. but, seriously, jki needs to fix this bug. i'd give more details about what causes it, but even after 20 hours of mucking with it i still have no idea what triggers it to do this.
  4. here is a set of files exhibiting the bug. steps: extract all files open package\.vipb goto "package dependencies" scan for dependency changes notice how no dependencies are detected this project has a package dependency on open g time library i'm using VIPM 2013.0.0.1893 my workflow would ideally not allow secondary dependencies like this, but since i am migrating 3k VIs into a hundred or so packages, it is something i'll have to transition through. my migration plan is: build every tool into a package. leaving all dependencies linked to source code switch over applications to use packages update all tools to point from dependency source code to dependency packages (this will take some time) NoDetectSecondDependency.zip
  5. Quick update on this ticket. With the introduction of the PMT (https://decibel.ni.com/content/docs/DOC-30858), we have no issues with renaming files any longer. We no longer need this request fulfilled.
  6. Good to hear that you're familiar with the issue! We're starting to migrate our 3k++ VIs into VI packages. This bug is a near-blocker for us at the moment. We can work around it, but it is going to add extra steps to our package validation process and increase the likelihood of bad packages getting out into the wild (and make VIPM look bad ). We'd appreciate any efforts you could put toward getting this one resolved. let us know if you need any more information or need us to do any beta testing. Thanks!
  7. ok. lets see if i can explain this clearly... i am trying to build A.vi into package A.vip. A.vi has a dependency on B.vi B.vi is not in the same folder as A.vi or the .vipb file for A.vip B.vi has a dependency on C.vip In the .vipb for A.vi, when i click "scan for dependency changes", C.vip is not detected as a dependency when A.vip is built, NO files from C.vip are included The workaround is to manually include C.vip as a dependency, but then why am i buying the pro version... is this expected behavior?
  8. sweet. i'll build my custom actions dependencies into a package and include that package in the build. any chance the "autodetect dependencies" option in the pro package could detect dependent packages in custom actions?? i know that at some point i'm going to forget to include the package. you've got a really good point about the search paths. i'll have to reconsider. we originally added our dev directory to our search paths because it is very painful to relink things manually when files are renamed and it net'd a time savings. maybe we could just get better at naming things...
  9. excellent! i'm glad this is not an issue. you may want to update your documentation to include the phrase "(system)" in it. i searched your entire website for that phrase and came up with nothing. well, of course, now this post will be returned...
  10. i create a package to install some glyph files my team uses. when i install it, it adds this additional (system) package that i didn't create. what is going on here? should i be concerned?
  11. i have custom actions in my build specification. these actions have dependencies that are not in vi.lib, nor in the package. when i install the package, it tries to find these dependencies. this leads me to believe that custom action dependencies are not included in the build? what should i do here? unpacking all dependencies to only include vi.lib code isn't a viable option. secondly, and perhaps the scary part, when the package is installed and the dependencies are not found, labview will search for the VI. in my case, i have my main development directory set as a search path in labview, so the installer will actually find the file from its source location. if it pulls in the files not included in the package, we've completely lost configuration control! it seems to me that the installer should never search for VIs and just error out, but maybe that isn't an easy task?
  12. agreed. my plan is to lock all package VIs in a post-install action. this will make it pretty obvious which ones are packaged even if they have the same name as the source files here's the idea related to the locking feature http://ideas.jki.net/topic/167870-allow-locked-no-password-protection/
  13. if the packaged file has renamed its dependencies, there will not be a name conflict with the old-nonpackaged version. A.viphas dependency X.vi that is renamed and packaged as A_X.vi[*]B.vip has dependency X.vi that is renamed and packaged as B_X.vi[*]Application.vi has dependencies X.vi A.vip that uses A_X.vi B.vip that uses B_X.vi so, as long as we can rename dependencies only, there will be no conflicts. you don't have to worry about using differing versions of X.vi because the version that was included in each instance was (hopefully) exhaustively tested to work when it was packaged
  14. Vote on the idea related to this ticket here http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/
  15. X.vi is a piece of reusable code that is shared by applications and other reusable code. They all link to the same location. I can't rename files when i package them. The manual re-linking effort is prohibitive.reusable code is used in reusable code reusable code library is used in 50+ applications no easy way to switch back to source code and debugcan't edit the package files directly. due to the differing names, changes can't be easily ported back into version control (SVN)[*]coincidentally, the code that needs to be distributed by VIPM the most is used in the most places and is most affected by this problem... [*]X.vi will eventually become a VIP. no question about this. The issue is that the process of packaging, deploying and validating each package cannot be performed in a single quick step where the normal rules would apply. workflow is: build X.vi into X.VIP re-link and rebuild packages that use X.vi to X.VIP re-link 50+ applications to X.VIP update VIPCs for all applications to include X.vip deploy new VIPCs and update applications on 50++ servers the applications are used on (we use dev environment for most deployments. reasoning is outside the scope of this post) for our code base this process can take days per package. We cannot devote all of our time to this task, so we have to assume that it will get interrupted by more immediate tasks, resulting in the need for code merging, etc. Having the ability to easily switch between source <--> package (when the package files are not the same name) would be a viable fix for this problem. Can you PM me with more information on availability of this feature? I have made a lot of promises about VIPM to my management (seemed like a good idea at the time...). Since this is a blocking issue, I need to give them some idea of the plan forward and a timeline to match. If you need clarification of any of the above, let me know. The more i help you, the more you help me
  16. i apologize, my estimates were a little off. there are 2300 VIs in our reuse library
  17. I am getting together a plan to build my large library (1500+ VIs) of reusable code into VI packages and migrate all applications using that code to pull out of VIPM/VIPCs. We must validate changes as we go, and we still have other work to do, so this will be a gradual migration. To make this even more interesting, we're the first adopter of this at our company, so any deployment issues will taint the reputation of VIPM forever, as our managers/counterparts are somewhat skeptical already. ok, now on to my problem... I have already built a few standalone\low-risk components into VIPs and they've work out quite well but now i'm moving on to more significant components and i'm having issues with shared VI dependencies (not VIP dependencies). here's the scenario: I build package A.vip and it has a VI dependency X.vi I build package B.vip and it has a VI dependency X.vi I have application Applicaiton.vi that has dependencies on A.vip, B.vip and X.vi (X.vi is directly contained in Applicaiton.vi) When i open Applicaiton.vi, I am unsure which X.vi will be used. Now, as a consequence of me applying configuration management, I have now completely lost configuration management Our deployment may last upward of 6 months, so i cannot get into this situation where we have lost configuration control. This will put us in crisis mode which will only further draw out deployment. also, we test rocket engines. you must always assume that every bug\problem has the potential to spontaneously ignite all propellant on site and result in a pretty bad day. To address this issue, i need to be able to rename VI dependencies only (add a prefix/postfix). I know that you can currently rename all packaged files and this is not a viable solution because it will make it extremely painful to move my applications/toolkits over to VIPs and i need to maintain the same file names between source code/package so that i can switch back and forth for debugging. I would assume that this feature would appear in the "source file settings" area as a separate item called "Dependencies". This would make it consistent with how the NI packed library build configuration dialog looks. i understand what implication this will have if you are using functional globals in dependencies and i'm okay with that. Let me know if you have any questions about this. As i stand right now, this is preventing me from migrating and consequently buying more VIPM licenses...
  18. build actions are only available in the pro version. i'm totally cool with this. the issue is, if a VIPB has build actions and you build a package with the free version, the build actions are not applied and you are NOT notified that these actions have been skipped. This is dangerous, as import things could be happening in these actions. Please update VIPM to error out if you are trying to apply build actions and do not have the pro version.
  19. I have also just discovered this...here's my thoughts: The lack of this feature is NOT covered in http://jki.net/vipm/compare nor the user manual. you can only find it by trying it out in the application. Not my favorite way to uncover a limitation... Your website states that if I buy pro i can "Use a VI Package Repository to share company add-ons and reusable code with your team". this is very misleading. I have purchased one Pro license and i'm evaluating it's worth to our team. If this eval goes well, I'm buying pro versions for our hard core LV developers (12 people) and setting up the LV tinkerers (100 people) with the free version. There is zero chance that we will be buying pro versions for the tinkerers. I cannot justify purchasing pro versions for them just so that they can use one feature. We run LV dev environment on all of our deployment machines (30 machines and growing). I understand that this is an atypical use case under your model (and NIs model). again, i cannot justify purchasing pro versions for these machines just so that we can use one feature. I would be perfectly happy if you increased the cost of the pro version and added this feature to the free version. I don't mind paying for developer features for developers, but i don't like being forced to buy the Cadillac version just to get basic features. As far as my eval is going, this is the ONLY potential blocker. If it wasn't here, I'd be rushing to move forward. Overall, I would like to really commend you on your product. It really solves some super tough LV issues in a quite elegant way. I look forward to the future power you will bestow upon us. (-:
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.