GetComponents does not correctly handle missing hg

Create issue
Issue #71 closed
Ian Hinder created an issue

I have tried to run GetComponents to checkout the Mercurial version of Carpet on a system where Mercurial is not installed. I get the error:

Use of uninitialized value in scalar chomp at ./GetComponents line 429. You have requested an hg checkout, but the system was unable to find hg. Please enter the path to hg: -----------------------------------------------------------------

at the start of the GetComponents output, but the checkout continues and finishes with

92 components checked out successfully. 0 components updated successfully.

Time Elapsed: 14 minutes, 25 seconds

and returns 0.

GetComponents should return a failure code in this case and not attempt the checkout. Log is attached.


Comments (6)

  1. Eric Seidel
    • changed status to open
    • removed comment

    The original idea was to allow users to provide the path to hg if it isn't on $PATH for some reason. Also, I don't think it's a problem to continue the checkout process and ignore hg components if hg is not found, as long as the user is warned that those components will not be retrieved. I'll look into the Perl warning though, and a more complete error message, giving the user an option to quit GetComponents, is probably in order.

  2. Eric Seidel
    • removed comment

    I see that it is actually trying to checkout the components though.. That should definitely not be happening.

  3. Ian Hinder reporter
    • removed comment

    If the user has tried to check out a particular thornlist, it is quite likely that the next thing he/she will try to do is to build it. If some thorns were not available, this will fail, when the real error was during checkout. The error should be caught as soon as possible. Regardless of whether the rest of the checkout proceeds, the exit code should definitely not be 0 if some components failed to check out. I am running automated build and test using GetComponents, so it is not being used interactively here.

  4. Eric Seidel
    • removed comment

    I decided to simply abort if a bad path to any tool is provided. My rationale for this is the following: in some cases the repositories are nested within another repository. In the Einstein Toolkit, the main Cactus thorn provides an 'arrangements' directory; however, if a user attempted to checkout all ET components except those provided via svn (granted this is a very small number), GetComponents would create the arrangements directory anyway. This would then cause more issues if/when the user decided to install svn and checkout the rest of the toolkit. I would prefer to ensure that a clean, complete checkout can be performed.

  5. Log in to comment