Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Curious pserve name=value behavior
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mike Orr  
View profile  
 More options Aug 21 2012, 4:33 pm
From: Mike Orr <sluggos...@gmail.com>
Date: Tue, 21 Aug 2012 13:33:41 -0700
Local: Tues, Aug 21 2012 4:33 pm
Subject: Curious pserve name=value behavior
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 <sluggos...@gmail.com>


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Michael Merickel  
View profile   Translate to Translated (View Original)
 More options Aug 21 2012, 4:39 pm
From: Michael Merickel <mmeri...@gmail.com>
Date: Tue, 21 Aug 2012 15:39:29 -0500
Local: Tues, Aug 21 2012 4:39 pm
Subject: Re: Curious pserve name=value behavior
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.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »