#1450 seems to have broken pecan

[dmick]

1450 seems to have broken Pecan, which subclasses WSGIApplication, and therefore doesn't use the "load" functionality of WSGIApplication.

The specific issue is that, since app_uri isn't created until WSGIApplication.init(), and since init() isn't called by BaseApplication.init(), object creation triggers a 'nonexistent attribute' error through BaseApplication.init -> BaseApplication.do_load_config ->WSGIApplication.load_config, which tests self.app_uri, which doesn't exist.

A workaround is to supply an unused app_uri in PecanApplication.init (called by WSGIApplication.load_config -> BaseApplication.load_config on its way), but that's obviously only a workaround.

As a suggestion only, because I'm certainly no expert on this code, maybe WSGIApplication.load_config should not require appuri, but rather wait to require it until the load functions (which are not used by pecan, and presumably not by other subclassers of WSGIApplication).

[aditya9729]

@dmick @benoitc , Is there any workaround for this? We are having conflicts between apache-airflow 2.2.3 (that requires gunicorn 20.1.0) and one of our product's services that requires gunicorn 20.4.0. If we bring in gunicorn 20.1.0 for airflow we find this issue persisting.

[dmick]

The workaround I found was to pin gunicorn, as the ceph/chacra bug above your comment shows. I haven't seen any interest from either the gunicorn or pecan teams.

[benoitc]

Well I don't know neither Pecan or Chacra. Having an example to reproduce it would help. Maybe as a test? I will check.

[benoitc]

no activity since. I saw some changes that may worth a PR if needed. In the mean time I think Tat can be solved by symply setting app_uri to wsg_app in the application init chacra or pecan.

[dmick]

Shrug. It clearly seems like a bug in the class implementation to me, but, motivation is a thing.

[benoitc]

@dmick well maybe a quick PR ? :) I can revisit that later if needed.

[dmick]

I'd have to be much more expert in the various use cases of BaseApplication/WSGIApplication than I am to be comfortable suggesting the "right" fix. For example, I'm initially drawn to calling WSGIApplication.init from WSGIApplication.__init__ as one might "expect", but I don't know what else that might break. It's a rework that requires some confidence in the code structure that I'd not have without a lot of study.

It's fine; we have our fix. I'm just vaguely mentioning the General Public Use.

[benoitc]

@dmick i think a correct fix would be simply ensuring that the BasApplication you inherit has by default the app_uri set to None. Ie something like

class BaseApplication(object):
    app_uri = None

or something like it. It's late ;) But a patch in that sense would probably work for any case.