seems that there are issues with that version that are yet unresolved. and some comments explicitely call @mdipierro to an action :P wolph/portalocker#2

I'd propose to always import the contrib version of portalocker until a new contrib version (inline with the pip version) is provided.
btw: the import in web2py are weird: there are already a few from gluon.portalocker and then few import portalocker

sadly, it's nothing new. web2py imports should always be used with gluon as the base, but up until now those kind of issues are not surfacing because web2py prepends the gluon path to sys.path. To be fair, this means that even if you have a pip-installed version of portalocker, inside web2py when you do "import portalocker" you're loading the gluon/portalocker.py one.

It seems that isn't like that for pydal imports.
I've tested and on both windows/linux, welcome app started only when I
removed the pip version of portalocker
By switching these imports
https://github.com/web2py/pydal/blob/master/pydal/_load.py#L12 it worked as
expected

Paolo

2015-03-08 13:36 GMT+01:00 niphlod notifications@github.com:

sadly, it's nothing new. web2py imports should always be used with
gluon as the base, but up until now those kind of issues are not surfacing
because web2py prepends the gluon path to sys.path. To be fair, this means
that even if you have a pip-installed version of portalocker, inside web2py
when you do "import portalocker" you're loading the gluon/portalocker.py
one.

—
Reply to this email directly or view it on GitHub
#832 (comment).

that's because - fortunately - pydal doesn't manipulate sys.path. I think at this point it's more of a pydal issue than a web2py one.