Ok so part of this sounds like a bug. Switching ports probably shouldn't happen in waitress given the ini snippets and usage you've pasted.
The var=value syntax isn't supposed to override arbitrary key/value pairs in an INI. Rather you need to insert placeholders into the ini such as "port = %(port)s". If you remember from PasteDeploy, the variables insert into [DEFAULT] actually override things defined in sub-sections unless you use the "set" keyword in a subsection. On Tue, Aug 21, 2012 at 3:33 PM, Mike Orr <[email protected]> wrote: > I have a small Pyramid application installed into two virtualenvs, one > for Python 2.7 and one for Python 3.2. The server section in the INI > file looks like this: > > === > [server:main] > use = egg:waitress#main > host = 127.0.0.1 > port = 5000 > === > > There is no [DEFAULT] section. When I run "pserve --reload > development.ini" under Python 2.7, it runs as expected: "serving on > http://127.0.0.1:5000". When I run under 3.2, it says "socket.error: > [Errno 98] Address already in use" because it's trying to use the same > port. So I tried to override this with: > "pserve --reload development.ini port=5001". Now it does something > unexpected: "serving on http://127.0.0.1:8080". Where did that number > come from? It turns out it's Waitress's default. (pserve.py also has > some 8080 defaults, but it looks like they apply only to Wsgiref and > CherryPy servers.) > > So why didn't it honor my 'port' specification, and why did it > apparently delete 'port' from the configuration instead? > > I looked in pserve.py to figure out if it applies command-line > variables to the server section, app section, or both. It looks like > it adds them to the defaults (global_conf). I assume that means these > are fallback values for the server and app sections, rather than > overrides. The user would expect them to be overrides, and may want > them to apply specifically to the server, app, or both. But in any > case, whether they're fallbacks or overrides, it doesn't explain why > the parameter is reverting to its upstream default value. > > Am i misunderstanding how command-line var=value are supposed to work, > or is this a bug? > > -- > Mike Orr <[email protected]> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
