Despite the fact that starforge is not using the latest starforge code, it is unable to determine root directory for whatever reason :(

@bgruening any hints on what the issues folks were encountering with uWSGI? There are two issues I can think of:

1. Older (pre-16.07) releases of Galaxy had threads starting before uWSGI forking, which could cause workers to deadlock and require a kill -9.
2. If you don't configure dedicated job handlers, uWSGI will attempt to run jobs and create chaos.

I'll get the Starforge build images updated ASAP, #109 needs to be addressed.

@jxtx: @nsoranzo brought the name change up in galaxyproject/galaxy#3179 and I can no longer remember exactly why this was done. My recollection is because you're building it as an extension class rather than the standard manner, so if someone got uWSGI from PyPI instead of us, it wouldn't work with our out-of-the-box config. Can you comment?

Because there are already uwsgi wheels on pypi, and this approach is
completely incompatible with them.

On Fri, Nov 18, 2016 at 11:33 AM Nate Coraor notifications@github.com
wrote:

@jxtx https://github.com/jxtx: @nsoranzo https://github.com/nsoranzo
brought the name change up in galaxyproject/galaxy#3179
galaxyproject/galaxy#3179 and I can no longer
remember why this was done. Can you comment?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE4ZUtqBysGm0gNsfambrv2_7LEDkOoks5q_dNigaJpZM4KkFGY
.

Yeah, ok, that's what I figured. If we used the same package name as upstream, would it be possible to support both styles in our out-of-the-box config? i.e. if the extension class build is available, use it, but if not, use command-line uwsgi?

Or was the problem not with starting the server, but starting the embedded server for functional tests?

The latter is where we stalled.
On Fri, Nov 18, 2016 at 11:41 AM Nate Coraor notifications@github.com
wrote:

Yeah, ok, that's what I figured. If we used the same package name as
upstream, would it be possible to support both styles in our out-of-the-box
config? i.e. if the extension class build is available, use it, but if not,
use command-line uwsgi?

Or was the problem not with starting the server, but starting the embedded
server for functional tests?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE4Zfs0i149__NQK4oHNdUgMxbkuQLRks5q_dUfgaJpZM4KkFGY
.

Might want to support the former then because in the majority of cases, people installing won't care about running tests but may want to pip install w/o using our wheels server (or more likely, forget to use our wheels server).

What I mean is that the former already worked. The latter was the problem.
On Fri, Nov 18, 2016 at 12:00 PM Nate Coraor notifications@github.com
wrote:

Might want to support the former then because in the majority of cases,
people installing won't care about running tests but may want to pip
install w/o using our wheels server (or more likely, forget to use our
wheels server).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE4ZaO6EAj49jRhlDblAS5XwEBnlTdZks5q_dm0gaJpZM4KkFGY
.

Right, two things:

1. Does our default config work with both?
2. This implies that perhaps we should keep the package name the same.

The config should work with both, but how you run it differs. I believe I
worked around this in run.sh so both would work. The name really should be
different.

-- jt

On Fri, Nov 18, 2016 at 12:12 PM, Nate Coraor notifications@github.com
wrote:

Right, two things:

1. Does our default config work with both?
2. This implies that perhaps we should keep the package name the same.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE4ZduiPmYOe8cjcbrjxUmooBVJj2Kjks5q_dyEgaJpZM4KkFGY
.

@natefoo I'm happy to help work on this - but I don't understand much of it.

• I'd say we should call it galaxy-uwsgi instead of pyuwsgi to make it clear this is a local modification and publish it both to wheels.galaxyproject.org and PyPI?
• I wouldn't hold up anything based on the functional tests yet - testing is still working in Configuration & Server Overhaul - Tool Shed and Reports galaxy#3179. I don't think we need an embedded server for most tests, if some tests do need it at some point - that is fine - some core portion of the core API should not require uWSGI at any point right? Fancy UI stuff like websockets will require it and the real functional web tests will not require an embedded server.
• I can try uninstall pyuwsgi in Configuration & Server Overhaul - Tool Shed and Reports galaxy#3179 and then retesting everything with a pip install from pypi - is that needed?

I'd say we should call it galaxy-uwsgi instead of pyuwsgi to make it clear this is a local modification and publish it both to wheels.galaxyproject.org and PyPI?

I called it pyuwsgi because that is what upstream calls it in their build configuration, see: https://github.com/unbit/uwsgi/blob/master/buildconf/pyuwsgi.ini

I don't think we should be publishing this to pypi. Installing Galaxy from pypi or packages should use upstream uwsgi packages.

I don't think we need an embedded server for most tests

I agree. I think killing the embedded server was the plan to move this forward. However the embedded server was/is still the default.

I can get in touch with the maintainers and discuss wheel options with them, if they're receptive to shipping wheels then we wouldn't need to maintain anything ourselves (once this version of uWSGI is released) and could just use whichever upstream name they used.