Initial copy of key parts of skare/py3

[taldcroft]

This is not functional, but will add these bits in original form to make a basis for subsequent changes.

[jeanconn]

I assume this will need a flt_envs from somewhere, probably sot/skare#168

[jeanconn]

(if we keep arch and need the scripts etc)

[taldcroft]

Yes, the Python flt_envs will be needed, but hopefully installed via conda package.

[jeanconn]

I thought you didn't want me to make conda packages that installed outside the conda root, and this was still going in SKA/bin not SKA_ARCH_OS/bin. Or are you just committing to #14 ?

[jeanconn]

It also looks like this is the sysarch version of install.py.

[taldcroft]

Ska3 fltenvs can be simplified:

• No sybase
• No arch
• No PGPLOT (maybe?!?!). A search of perl code files in the SOT org showed no real dependencies. I must be forgetting something.
• Does conda already put $root/lib into LD_LIBRARY_PATH, so we don't need to?

[taldcroft]

Yes, I want to go down the path of #14 unless a real showstopper turns up.

[jeanconn]

That's fine. If we go down #14, I didn't think we'd need flt_envs or the wrapper scripts at all.

Wrt PGPLOT, I thought it was mostly used for cron tasks like astromon that would be a bonus to support with our new environment.

[taldcroft]

If we can drop PGPLOT from Ska3 that would be awesome, almost worthy of a celebration for all the hassle that package has caused over the years. I'm fine letting astromon churn along in Ska2 until something else (system upgrade) breaks it. Then we would be motivated to rewrite in Python.

[taldcroft]

We probably still need a flt_envs because the process of source /proj/sot/ska/bin/ska_envs.sh is so embedded. If nothing else putting Ska3 into the path in a consistent way with legacy is worth it.

[jeanconn]

If we keep the wrapper script syou could just set SKA from them and be done (without needing to source flt_envs).

[taldcroft]

I'm not getting you. How to users get (e.g.) /proj/sot/ska3/flight/bin/ipython into their PATH? (Here ipython is the real binary, not a wrapper, assuming #14).

[jeanconn]

I don't remember the subtleties of making sure you have a useful absolute path in bash, but I just figured that ska_envs.sh or ska_envs.csh would just set PATH and SKA and not need to call a python script.

#!/bin/sh                                                                       

SKA_bin=`dirname $0`
SKA_bin=`readlink -f SKA_bin`
export PATH=${SKA_bin}:${PATH}
SKA=`dirname ${SKA_bin}`
SKA=`readlink -f ${SKA}`
export SKA=$SKA

[jeanconn]

But my demo idea doesn't work, and I've forgotten my rules about dirname (does "source"ing a script work if it calls $0"?). It is certainly fine to also keep a flt_envs if all flt_envs does is something equivalent without needing to figure it out for both csh and bash (you only need one flt_envs and then it works from each shell).

I note had this in the bash flt_envs prototype

Ska_bin="$( cd "$(dirname "$0")" ; pwd -P )"
SKA=${Ska_bin%/bin}

[jeanconn]

I guess this works for bash

SKA_bin="$( cd "$(dirname "$BASH_SOURCE")" ; pwd -P )"
export PATH=${SKA_bin}:${PATH}
SKA=${SKA_bin%/bin}
export SKA=$SKA

[taldcroft]

Your original comment confused me because you said only to keep the "wrapper scripts", and I don't count ska_envs.* as wrapper scripts. But in any case for production we still do need all the other stuff in flt_envs. It will certainly get thinner for Ska3, but not so much that it's worth writing/maintaining separate csh and sh versions.