Review Windows Support Options.

[petersilva]

We don't use windows a lot... Maintenance of the windows binary is, in practice, quite troublesome. It breaks often,
Installation, using WSL, or docker containers... could be easier to support and address reasonable amount of cases.

[petersilva]

• get docker container test implement as a github Action?

• for WSL, the instructions become get a linux prompt... then follow existing linux instructions.

[reidsunderland]

@codeavenger456 is going to give WSL a try.

These instructions worked to get flow tests running on a fresh Linux VM, hopefully they will work the same on WSL:

sudo apt update
sudo apt upgrade -y
sudo apt install git

git clone -b v03_wip https://github.com/MetPX/sarracenia.git sr3

cd sr3

travis/flow_autoconfig.sh
travis/ssh_localhost.sh
# may need to type yes, press enter, then try travis/ssh_localhost.sh again

---

# Test ssh to localhost without password
ssh localhost ls 
# Should show directory listing. Should not ask for password.

---

# Logout and back in to set the PATH
exit
ssh user@server

# Check the path
echo $PATH
# Should contain /home/yourusername/.local/bin

---

# Try to run flow tests
cd ~/sr_insects/static_flow
./flow_setup.sh
./flow_limit.sh
./flow_check.sh

# When finished:
./flow_cleanup.sh

[rickyychen]

Cannot connect to ssh localhost after configured the ssh secret key

Have to manually start a ssh server before connecting to localhost sudo service ssh start

[rickyychen]

systemctl does not work on WSL and will produce the following error:

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

The equivalent of systemctl of Linux is equal to sudo service of WSL

[rickyychen]

If the system has already setup sarracenia servers then we should run the clean up script to simulate a new environment

[petersilva]

• Having stuff working on docker and WSL is a big improvement. It gives people options.

• The work so far has covered running the flow tests on windows... and WSL and docker are good for that.

The intent of this issue was to clarify end user options for running sr3 on Windows.
there is a script called generate_win_installer.sh that builds a self-extracting windows
installer file. We used this to generate a native windows application in the past.

Since the last time we tried.. it was quite painful to generate packages because of conflicting version requirements of dependencies. This causes problems in many constrained environments, and the work to clarify /modularize dependencies can benefit the windows binary generation.

for windows, we just accept that polling FTP servers is not going to be supported at all,
and if we do that, then we don´t need any of the date-time dependencies (this brings in dozens of python modules.)

the dependencies went from being all mandatory to a mix of mandatory and extra.
here is the corresponding stanza in setup.py

    install_requires=[
        "appdirs", "humanfriendly", "humanize", "jsonpickle", "paramiko",
        "psutil>=5.3.0", "watchdog"
    ],
    extras_require = {
       'amqp' : [ "amqp" ],
       'ftppoll' : ['dateparser' ],
       'mqtt': [ 'paho.mqtt>=1.5.1' ],
       'vip': [ 'netifaces' ]
    }) 

So for building the the windows package should include the mandatory dependencies ...
and likely amqp, perhaps mqtt also... vip might be optional, but leaving out dateparser.

might want to try generate_win_installer with a reduced set of deps to see if we
can do it again (last time failed because of dateparser)

[andreleblanc11]

I've been running through problems recently when trying to run the flow tests on WSL. When running sudo service rabbitmq-server restart, I was getting this error message.

unable to connect to epmd (port 4369) on $HOSTNAME: address (cannot connect to host/port)

The problem has been resolved now. Turns out localhost wasn't recognizing me as the host since $HOSTNAME was missing in /etc/hosts.

Forum reference:
https://stackoverflow.com/questions/29142877/windows-unable-to-connect-to-epmd-port-4369-on-sysname-address-cannot-conn

[petersilva]

#721 is a severe issue the user had that resulted from a lack of testing of windows prior to the release, so not realizing that a new dependency would not work on Windows. The interesting thing here is that the user does not even use the Windows executables we package, but pip install from a standard python distribution.

So to "properly" support Windows would mean running all the python distros that people use cpython, Conda, IronPython, as well as an executable? The user makes a point that in his case he wants to use plugins, and finds it hard to understand how that work work with an EXE based distribution. I find it challenging to understand as well how one would add dependencies used by plugins.... I guess only usage with only built-in plugins would be supported by EXE distribution.

[petersilva]

Also... some sort of dependency inventory... #738 is one way to do it...
might be helpful.

[petersilva]

• issues relating to installation on windows: The Windows installer is not signed  #133, Permission issue with [email protected] or exchange xpublic not found. #355, windows installer generator broken #368, windows binary generation broken by dateparser dependency. #479, Windows' pip install metpx-sr3 leads to a missing directory #484,

• OS specific issues (we have a tag for that):
  https://github.com/MetPX/sarracenia/issues?q=is%3Aissue+windows