#pyramid

nope!

fair enough

sorry it's just frustrating when things are out of my domain but under my control

though you'd rather not get a pull request using the library from above, right?

we avoid dependencies if possible, but I'd have to vet the library and ensure that it looks actively maintained / reputable versus some rando github repo

yep

sorry to stir the pot

don't take my ranting personally please

raydeo: i don't have https everywhere. Nor do I really care :P

I'm sure it comes off that way

does not, actually

I don't use colander anymore, but I will see about doing a PR for the regexes later tonight.

i know maintenance, upkeep and release cutting are hard

I maintain colander only because it looks very bad for pylons as a whole to abandon projects

That's the reason I have been swooping in and doing releases of various projects...

yeoman's work to be sure

hi, is it possible to get transaction.manager from a dbsession? I mean after get_tm_session / zope.sqlalchemy.register is done

what are you trying to accomplish?

rweir: I just though of sparing an "import transaction" in multiple files, but I think it is needed. I'm running an async worker (huey) where I cannot just call functions under a main "with transaction.manager", and I thought transaction.manager might be accessible such as dbsession.tm or something similar

hyperknot: request.tm is the easiest

there is not a way to get the transaction manager from the session though... it is a one-way relationship

... unless you tack it into the session yourself

raydeo: but I don't have a request, and also the input of my function is a dbsession not request. you are right I could convert my function to take a request instead of a dbsession and try to create a fake request, but "import transaction" in multple files seems to work fine

yeah if you are using the threadlocal then you can just import transaction

the *right* solution is to pass them both around if they are both needed possibly by grouping them into a single object that you pass around

yes I wasn't sure if it is referring to the same transaction or not

it's not necessarily

it depends on what you pass into get_tm_session

raydeo: an "import transaction" in the main worker module, gets inserted as get_tm_session(session_factory, transaction.manager)

right... in general you should try not to use the global transaction manager but it does work if you do

huey is configured to use one process per worker, so I believe evey python process can only see one transaction module

transaction.manager is threadlocal

read this section for my thoughts on the issue http://docs.pylonsproject.org/projects/pyramid-...

raydeo: I've based my cli scripts on this one: https://github.com/Pylons/pyramid-cookiecutter-...

ok

raydeo: your doc is more about web environments with app and so, isn't it?

yes but the caveat on threadlocal manager is important regardless

the explicit manager can help find bugs

raydeo: but only in case i'd use multithreading or greenlet or gevents or something more exotic stuff, doesn't it?

well certainly as the environment gets more complex the more it helps... it all depends :-)

I'm a big fan of starting out as complex as possible ;-)

I've just refactored everything in a project from older global DBSession to request.dbsession, so that's quite enough for today, I'll just stick with simple CLI scripts based on initdb

sounds good!

I imagine that was a little tedious

you'll have to let me know if it was worth it

I just had to triple check how every single function is called. the trickiest one was this huey task queue which is so "magic" that it just cannot pass a dbsession to a function

raydeo: the result that I now have similar codebase between two projects I'm currently working on is definitely worth it

great!

I hope dearly that plaster in pyramid 1.9 will help make scripts easier to write.

We need to make a new file format that supports better inheritance between config sections and then it definitely should.

i'm looking forwards it