search

MetPX / sarracenia

https://MetPX.github.io/sarracenia
GNU General Public License v2.0
45 stars 22 forks source link

Review Windows Support Options. #528

Open petersilva opened 2 years ago

petersilva commented 2 years ago

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 commented 2 years ago
reidsunderland commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

petersilva commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

petersilva commented 1 year ago