Running Dev server on Windows

[geoffjukes]

Hi,

I love this project by the way - it made my life so much simpler!

I just upgraded to 2.01 and now my Dev server won't start. I'm probably doing it all wrong anyway, so I hope someone will steer me right.

I have a small 'run.py' script that sits outside the API package I wrote, and it calls __hug__.serve()

This worked on 1.9.9, but after upgrading to 2.0.1 it throws this error:

  File "U:\API\.env\lib\site-packages\hug\use.py", line 171, in Socket
    'unix_stream': (socket.AF_UNIX, socket.SOCK_STREAM),
AttributeError: 'module' object has no attribute 'AF_UNIX'

I tried switching to use hug.API(api).http.server(), and even a crude call(["hug", "api"]), all with the same error.

Am I being dumb? or was there a change that broke Windows?

Thanks!

Geoff

[kirklg]

Sockets work differently in Windows (unix sockets dont exist), I'll see if I can push a bug fix tonight.

[geoffjukes]

@kirklg that would be amazing, thank you (and glad it's not me being dumb!)

The production server will be uWSGI on Ubuntu, but for Dev I have to work in Windows.

[timothycrosley]

Hi @geoffjukes,

I'm glad hug is working out for you! We're very happy to have you as a user :) I'm very sorry that hug 2.0.0 broke Windows, I've pushed an emergency fix to resolve this issue, that essentially only creates the use.Socket class if unix is detected. Please let me know if this fix works for you it is pushed as release 2.0.2. I'm going to be thinking about ways to run the automated tests on Windows to keep issues like this from happening in the future.

Thanks!

~Timothy

[geoffjukes]

@timothycrosley Amazing response, thanks!

I still can't get it running. At first I had an issue because I used falcon-style middleware calls. I changed then to the @hug.request_middleware, and the error went away.

but now it just terminates with "Process finished with exit code 0".

My apologies, I am typing this on my phone via a remote desktop.

[geoffjukes]

@timothycrosley pretty sure this one is my fault. My whole dev environment just went wonky.

[geoffjukes]

@timothycrosley Its not my environment. I just rebuilt everything, and the server just exits.

I reverted to 1.9.9 until I'm back at my desk and can debug properly. I know there were other changes in 2.0, and it could be one of those.

[kirklg]

@tcrosley, this sounds like the issue we saw when cython compiled types.py. But this is on windows, could be a different issue.

@geoffjukes, you mind verifying that types.py was compiled with cython, if so you could try removing the .so file and try rerunning in 2.0.

[timothycrosley]

Hi @geoffjukes, the issue may simply be how your starting the server:

can you try switching out:

hug.API(api).http.server()

for:

hug.API(api).http.serve()

And report back? The server function creates the wsgi compatible server object, but by it'self it wont function. The serve command is what runs the development server forever locally.

In the meantime windows testing is getting close! https://ci.appveyor.com/project/TimothyCrosley/hug/build/1.0.19/job/nt3vg2tkub68rran

Thanks!

~Timothy Crosley

[geoffjukes]

@kirklg When my env went wonky, I started from scratch, and cython wasn't installed. I am running python 3.4.4 (if that is relevant). I updated to 2.0.2 just to test again, and it still fails to start.

[kirklg]

Silly me, cython is probably not being used here. Please disregard my previous comment.

[timothycrosley]

@geoffjukes in case you missed my previous comment since we posted at the same time >.< can you try switching out:

hug.API(api).http.server()

for:

hug.API(api).http.serve()

? I think this may fix it

[geoffjukes]

@timothycrosley that's why you get paid the big bucks :) That fixed it, and I'm now on 2.0.2. Thank you for the quick update and the help.

Just a heads up that I had to switch my middleware to the decorator style too, as the falcon-style wouldn't work for me. In case the docs need updating.

Great project, Great response!

Thanks guys.

[timothycrosley]

So glad we could help resolve your issue! For future reference you should be able to use Falcon style middlewares as long as you switch from __hug__.add_middleware to __hug__.http.add_middleware or hug.API(__name__).http.add_middleware this is briefly documented in the change-log as: "API singleton now has sub-apis for each interface in use (IE hug.API(name).http and hug.API(name).cli)" but more documentation there would definitely be helpful.

Thanks!

~Timothy