Python installs fail to generate mdsplus.pth

[WhoBrokeTheBuild]

trafficstars

Two problems here:

• setuptools seems to have deprecated extra_path (in like 2016), which is what we're using to generate the mdsplus.pth file, which is what allows you to import MDSplus in python
• Running setuptools on mdsplus-alpha-python is now configured by an environment variable
  • This is impossible to set from ansible scripts
  • This causes the default behavior on install to create a broken installation

On Ubuntu 18, doing a stock install

sudo apt install -y mdsplus-alpha mdsplus-alpha-python

This will install the MDSplus python package correctly to /usr/local/mdsplus/python/MDSplus, but it will not create any mdsplus.pth files, meaning that you cannot import the package.

I recommend we get rid of setuptools entirely, and just generate the files manually during python_module_install.sh

Thoughts?

[zack-vii]

sound good to me. in general we should possibly get rid of sertup.py entirely or modify it so it will simply compile and generate the mdsplus.pth when run as python /usr/local/mdsplus/python/setup.py.

[WhoBrokeTheBuild]

That sounds good to me

So, empty out setup.py and replace it with the following logic:

find path of site-packages for this python version
I think it should try to find `python3/site-packages` instead of the version specific `python3.6/site-packages`

get the mdsplus python path
$MDSPLUS_PATH + /python/MDSplus

write mdsplus.pth in that directory with that path

Then, I would remove the MDSPLUS_SETUP_PY variable from the python_module_install.sh and just always call setup.py from each valid python interpreter

Sound good? If so, I'll start working on a PR

[ModestMC]

@WhoBrokeTheBuild will this get fixed (and thus be closable) after Sterling's suggestions get integrated?

[WhoBrokeTheBuild]

Not immediately, we'll need to put in a second PR to update the packaging scripts to call the new setup.py properly