Looks helpful to make the alosStack setup more similar to the topsStack and stripmapStack setup.

This change requires adding $ISCE_STACK to $PYTHONPATH

What if we also install topsStack, stripmapStack, etc along with the other python modules? Then we can simply import isce.components.contrib.topsStack instead of having to modify environment variables.

@rtburns-jpl I think the problem is that topsStack and stripmapStack have command-line programs with the same name but slightly different functions. That is why @hfattahi kept them separate and we have to add one or the other to the $PYTHONPATH and $PATH to do the processing workflow.

Yeah, we wouldn't be able to install the applications in a flat namespace, so if you wanted to simply run geocodeGdal.py you'd need to add the appropriate directory to your PATH. But we could still install them to the python module directory, so we could also call them unambiguously via e.g. python3 -m isce.components.contrib.topsStack.geocodeGdal

If installed via conda, all the stack processors are currently included in the envs/*/share/isce2 folder, whose path is saved as $ISCE_STACK. I don't know why they are not installed to /envs/insar/lib/python3.8/site-packages/isce directory, whose path is saved as $ISCE_HOME, which is accessible via import isce.*.

Since topsStack is more frequently used in its development version (for me at least), is there an easy way to point isce.components.contrib.topsStack to a non-interpreter directory?

Although the current way of adding $ISCE_STACK to $PYTHON_PATH from this PR is not ideal (as described in @rtburns-jpl comments above), it's consistent with the current setup style of adding $ISCE_STACK to the $PATH. I would suggest that we merge this PR before the new release.

We should decide today or tomorrow whether to merge this before we freeze version for the UNAVCO 2022 short course. I don't understand enough about how Python works to advise on the details.

This change requires adding $ISCE_STACK to $PYTHONPATH, thus, would break the previous default setup for stack processors.

If I understand that correctly, we definitely shouldn't merge something breaking for a bugfix release. I think we can come up with something that will not break existing setups, and will make the stack more programmable without involving more env variable trickery.

If I understand that correctly, we definitely shouldn't merge something breaking for a bugfix release.

Yeah, I agree with this.

I think we can come up with something that will not break existing setups, and will make the stack more programmable without involving more env variable trickery.

I would argue that:

1. the existing setups are manual already, this PR would bring one more line of manual setup, plus a few setup note simplifications to improve the style consistency, thus, it's clear and simple to adjust on the user side, in terms of breaking change;
2. in the logic of "functionality is more important than elegant implementation", the programmable workflow (which is vital in my own processing) is still worth merging before we find out a better way, which would require other changes that may deserve its own PR.

Thus, I would think it is good to be merged, probably after the currently planned next bugfix release.

Adding @hfattahi and @piyushrpt to see if they have opinions on this.

@rtburns-jpl I think this is useful functionality and would be nice to merge. You can increment the minor release and make it clear in README of the release what users need to change to be able to keep running the stack processor. @yunjunz can help with that clarification.

Ok sounds good, thanks. I'll include this in the next feature release.

Thanks, @hfattahi and @rtburns-jpl. Here is a note for clarification in the release:

NOTE: Since this release, users should add ${ISCE_STACK} to their ${PYTHON_PATH} to be able to keep running the stack processors. For bash users, e.g., it's: export PYTHONPATH=${PYTHONPATH}:${ISCE_STACK}. Check more detailed instruction in the README file.

@rtburns-jpl When you have some time, I think this is a substantial change to ISCE2 that would merit at least a minor version bump.