conda-forge jigsaw not playing nice with jigsaw.m about jigsaw-geo-matlab HOT 6 CLOSED

@xylar: yes indeed! I think this is mostly an issue that will be sorted when 0.9.10 becomes a thing, but the local vs ../usr/bin/ install issue might require a little more thought.

In terms of naming -- previous JIGSAW's have had an unnecessarily complicated naming scheme, with binaries placed in OS-dependent directories, and the trailing characters denoting the type of binary: 64r = 64-bit release, 32d = 32-bit debug, etc. At the time, this all seemed like a good idea to me, but I think I regret it now! It seems that just doing the simple and obvious thing will make life with cmake much more straightforward across OS's, etc, and I'm thinking that 0.9.10 is a good opportunity to make a change here. I'll update the MATLAB interface scripts to point to the proper places when 0.9.10 is live.

The local vs path-based install question is a little less clear to me though. Installing to ../usr/bin/ etc will work fine for Linux machines, but potentially less well for other OS's. My thinking with keeping everything local is that this works everywhere, and allows for multiple JIGSAW's to be installed side-by-side. I'll see what I can do on this though -- it might be possible for me to get the MATLAB scripts to look for binaries in the path first, and then fall back to local directories if necessary...

from jigsaw-geo-matlab.

The local vs path-based install question is a little less clear to me though. Installing to ../usr/bin/ etc will work fine for Linux machines, but potentially less well for other OS's.

First, conda environments install to a path in the virtual environment (something like ~/miniconda3/envs/jigsaw/bin) rather than to a system path like /usr/bin or /usr/local/bin. This is true on all OSes, so nothing specific to Linux.

I think trying for a jigsaw command in the path would really be the only way to make the jigsaw conda package useful in connection with jigsaw-geo-matlab, and I think this should be both possible and useful for all OSes. I know how to do this in python in an OS-independent way but I'm far too rusty on Matlab to be able to help with the details.

My thinking with keeping everything local is that this works everywhere, and allows for multiple JIGSAW's to be installed side-by-side.

This would be like a debug and a release? Or do you mean multiple versions of the code? Because I wouldn't expect most users of jigsaw-geo-matlab to need multiple versions of jigsaw itself (and conda environments could take care of that anyway if they do).

I'll see what I can do on this though -- it might be possible for me to get the MATLAB scripts to look for binaries in the path first, and then fall back to local directories if necessary...

Yes, that's exactly what I was hoping for. Like I said, without this, jigsaw-geo-matlab can't be used with the jigsaw conda package, which makes the conda package a lot less useful to those of us working on MPAS.

from jigsaw-geo-matlab.

@xylar: I think I've made some progress on this now -- the -dev jigsaw(geo) branch should be up-to-date with the 0.9.10 release candidate.

I've re-worked the jigsaw.m and tripod.m interfaces so that they can run both local jigsaw binaries and those found on the path. The routines first check for a local binary, and, if not found, make a global call. I've checked that this is able to toggle between binaries installed in /usr/local/bin and local directories.

Hopefully this should now work consistently with conda. If you have a minute to check on this let me know, and if all looks good I'll update everything to master and make a 0.9.10 release for conda.

from jigsaw-geo-matlab.

Sounds great! I'll try this out right now.

from jigsaw-geo-matlab.

Yep, that seems to work great with the conda-forge version of jigsaw! Thanks for this update.

from jigsaw-geo-matlab.

Great! Thanks for your help with this.

from jigsaw-geo-matlab.