Finding Larch server

[bruceravel]

@newville : In the recent PR, the find_larch function is pretty much guaranteed to fail on a linux machine. The function presumes that "python" and "larch_server" are in the same location in the path, which I am guessing is the case with anaconda.

I want to add a check for those two executables prior to your loop through @dirlist using the File::Which module, which is already a Demeter dependency.

use File::Which qw(which);

later...

  my $pyexe_ = which($python_exe);
  my $larch_ = which("larch_server");
  if ((-e $pyexe_) && (-e $larch_))  {
    $larch_exe = "$pyexe_ $larch_";
    return $larch_exe;
  }
  foreach my $d (@dirlist) {
    my $pyexe_ =  File::Spec->catfile($d, $python_exe);
    my $larch_ =  File::Spec->catfile($d, $pyscript_dir, 'larch_server');
    if ((-e $pyexe_) && (-e $larch_))  {
      $larch_exe = "$pyexe_ $larch_";
      last;
    }
  }
  return $larch_exe;

In the case where python and larch_server are locatable in the path using whatever mechanism File::Which uses, then we are good to go. If not, then, we can dig through your hand crafted list of potential paths.

It works for me and I doubt that it will break for you.

[newville]

@bruceravel

@newville : In the recent PR, the find_larch function is pretty much guaranteed to fail on a linux machine. The function presumes that "python" and "larch_server" are in the same location in the path, which I am guessing is the case with anaconda.

And on Mac OSX and on Fedora/CentOS too. System python on Fedora/CentOS is /usr/bin/python and installing with that does install to /usr/bin/larch_server. It is different on Debian/Ubuntu?

I think that is "normal python behavior" (even for Apple or Macports Python which uses the wacky version Frameworks thing, the executables get installed next to python). Windows is a special case, with the main executable is {C:/Python27}/python.exe and runnable scripts going to {C:/Python27}/Scripts/larch_server.

I want to add a check for those two executables prior to your loop through @dirlist using the File::Which module, which is already a Demeter dependency.

OK. @dirlist does include the PATH variable -- does File::Which do anything more than that? Except that the test you have might be happy to find python and larch_server in separate places. But that could indicate a problem / version conflict.

For Linux (and Mac for that matter), it's probably fine to simply drop $pyexe altogether, as larch_server should be chmod +x and will invoke python via #!/usr/bin/env python.

[bruceravel]

@newville : On my ubuntu/debian machines, the python executable in in /usr/bin, as expected [*] for something installed by the package manager. larch_server is in /usr/local/bin, as expected for something not installed by the package manager. My problem isn't with using the hand-curated directory list -- it is with the requirement that the two be co-located in $PATH. File::Which offers a quick and easy API to resolve the problem in a way that works on lots of platforms, but does not do anything more than a search through $PATH on a unix-y system.

Co-location does not preclude the possibility of a version conflict. Requiring co-location simply failed on my Ubuntu machines.

If you are comfortable not using $pyexe_, I have no problem with that.

[*] well ... expected in the sense of doing what the Linux Foundation Filesystem Hierarchy Standard suggests, which is not uniformly adopted and probably not observed by non-Linux systems.