#pyramid

hrm

https://bpaste.net/show/3ee8c7c6f4d9 :[

pyramid_tm and setup.py upload don't play nicely together :/

dstufft: setup.py?

dstufft: did you incidentally trigger the start of a transaction during a setup task? I'm confused

benbangert: trying to upload a package to Warehouse (running pyramid w/ pyramid_tm), the body that setup.py sends makes webob made becuase of something pyramid_tm does, the make seekable thing I think

oh, during an upload test

makes webob mad*

I'll have to figure out how to work around that, becuase I can't replace setup.py upload :/

dstufft: the traceback you posted there is an exception raised by webob...

I dunno why thats pyramid_tm's fault?

benbangert: yea, the except comes from webob, but pyramid_tm is the thing that calls request.make_body_seekable()

it's probably actually webob's fault, but pyramid_tm is triggering the code

is all I meant

my guess, would be that pyramid_tm is attempting to ensure the body can be copied up before deciding to continue with the transaction

rather than trying other ops that may have side-effects it can't back-out of

yea, it appears pyramid_tm does that if your attempts are > 1 so it can rewrite and retry

rewind*

right, but I don't really understand why pyramid_tm is involved at all during a setup.py operation

setup.py upload is the client that's making a request to a pyramid site

oh, this error is out of Warehouse?

yea

so why is the webob error occuring?

https://github.com/Pylons/webob/blob/master/web... looks like that

hr

hrm

gonna have to jump in and read the bytes before pyramid gets ahold of em It hink

you have debug toolbar running, why not just look there and see what the value is?

could've sworn there was an interactive debugger that would let you jump in

dstufft: http://docs.pylonsproject.org/projects/pyramid-...

looks like you need to set that setting to 'debug', and it'll retain the full traceback stack for exploration

benbangert: meh, nc -l works too :)

for seeing what setup.py is sending

https://bpaste.net/show/8da21c852762 >:[

uhhh

dstufft: is that good or bad?

I think it's a well formed thing

cetainly everything has a name

all the names look intact, I'm guessing it might be missing the assumption you would include a section with no content

trying to figure out why webob doesn't think it does

so yea, that debug setting.... ;)

ya

i'm epxloring now

so beautiful outside, time to walk the dogs before some more Rust

mmm rust

i can't wait for rust to be web-ready

dstufft: you find the prob?

benbangert: partially, it's not webob's fault I think

I think it's the cgi module's fault

which is :sad trombone:

empty multipart section causing it?

I think it's because there's a leading \r\n

heh

Python 3 broke it

https://bpaste.net/show/1facd6decbdc on python2 that passes without error, on python 3 it gets an AssertionError unless I uncomment the lstrip

but yea, I dunno why everyone doesn't use Python 3..... :(

blaflamme ok, that sounds reasonable, provided we use a style: a.reference.internal em {font-style: normal;} Sphinx applies HTML markup to links in lists and paragraphs differently

you want me to do the submodule dance on this?

how do I configure the pool_size on my beaker sessions when using ext:database? I have it working on an older pylons project, but in a newer pyramid one it doesn't seem to be having any effect, so I'm convinced I'm doing something wrong

supplicant: the ext:database should contain the additional options to change

benbangert: I'm doing session.sa.pool_size = 200 (also tried beaker.session.sa.pool_size = 200 without luck)

does that look remotely close?

or am I misunderstanding what you mean by

"the ext:database should contain the additional options to change"

Does webob allow patches that work around broken Python 3 behavior or do you have to patch Python itself

might depend on what broken behavior, because there's broken stuff that won't be fixed, I'm sure, for hysterical raisins

historical rosins

hrm

dstufft: we have compat modules to work around py3 problems

dstufft: so yes

goodwill: I'm not even sure a good way to work around this issue now that I think about it more :( It's a problem with cgi.FieldStorage, and fiixng it basically means you have to subclass FieldStorage and copy/paste a single method out of the python3 code base and patch that method

I mean I can do that, dunno if webob wants a whole method copy/pasted out of python3 though

hm

I'll submit a patch and y'all can decide if you hate it or not

dstufft: here is what we have in pyramid compat ... it is not small https://github.com/Pylons/pyramid/blob/master/p...

dstufft: we has to copy paste all kinds of things

s/has/had

goodwill: https://github.com/Pylons/webob/pull/190

dstufft: it looks good to me but as I never did anything with Webob is it ok if I ask raydeo or mcdonc to review and pull in?

goodwill: sure

mcdonc, raydeo : lil pull request review love? https://github.com/Pylons/webob/pull/190 ?

I'm already using a fork of webob for https://github.com/Pylons/webob/pull/189

so keeping using one for this one too isn't a big deal

dstufft: actually I suggest a tests for 190 .. one that tests for py2 and one for py3

dstufft: probably also a test for stale* bits too

goodwill: what would the tests for #190 test? I mean I can copy/paste the multipart test suite from the stdlib too... but it seems silly to duplicate the tests from the stdlib?

Pylons/pyramid: issue #190 (2011-05-14 CLOSED): "Correct a typo in my surname" by wichert: https://github.com/Pylons/pyramid/pull/190