update ats_hello ats path discovery

[davidbloss]

ats_hello had baked in assumptions that the system python had ATS installed in its site-packages directory.

[dawson6]

I am confused as to how this will find where ats is?

dawson@rzgenie2/HelloATS > ./ats_hello Traceback (most recent call last): File "./ats_hello", line 8, in import ats ImportError: No module named ats

[dawson6]

This now uses the system python, and attempts to import ATS, but the location is not known. How would this work with say a specific install of ATS in public such as /usr/gapps/ats/toss/7.1.1

!/usr/bin/env python

import os import sys from subprocess import Popen sys.dont_write_bytecode = True

import ats

[dawson6]

So this does work If I update my path like so:

export PATH=/usr/gapps/ats/toss_3_x86_64_ib/7.0.5/bin:$PATH

and then /usr/bin/env python finds the python in there which knows how to import the ats module.

Is this the intent, that folks would update their path? I can see this causing issues if folks want to use public python for some things and ATS python for running ats.

But I don't yet understand the mechanics of the new setup method, so I am a bit ignorant here.

[davidbloss]

Addressing the comments from top to bottom:

1) How does ats_hello find and import ats?

• This assumes the user has installed ATS.
  • As of now this likely means via some pip install as documented in #39
  • Testing this assumption can be done by running python then import ats.

2) How would the system python know about ats in a place like /usr/gapps/ats/toss/7.1.1 ?

• Depends how /usr/gapps/ats/toss/7.1.1 is used. If this path contains a separate python executable that is referenced at the top of a script, then the system python isn't really be used.
• If /usr/gapps/ats/toss/7.1.1 is a shared readable path that contains libraries then this directory would need to be added to sys.path at some point in a script. This is not advised.

3) Yes, updating $PATH could be used to find the top level ats script. But as you mention, this imposes a burden and added layer of confusion on the users.

At some future date all of the users of ATS should upgrade to some stable Python 3 version. Once everyone is on the same page we can host ATS on LC's python wheelhouse and if it makes sense, upload it to pypi.org for users lacking LC access. This would greatly simplify setting up ATS.

[dawson6]

Am wondering if there is a way to make ats_hello work

1) without updating $PATH or other env vars 2) using the global installed ATS (not user or project install) in /usr/apps/ats/x.y

The current update does not do so.

I ask, as that is how our project switches to a new ATS vesrsion. It is similar to how the ats_hello was using it, it was specified in the first line of the file.

It may not be the end of the world if we have a different method for the ats_hello test. As long as the prior method to use the global install is still workable for projects to use.

But I need to know the method for testing ats_hello on the public install. If it is via some PATH that could be fine, I would just need to update my testing procedures for when I do a public install

Assuming you or Chris are on top of making this workable with a continuous integration test for pull requests.