Re: [pylons-discuss] migrating away from formencode?

2020-10-05 Thread 'Jonathan Vanasco' via pylons-discuss
Talk about timing. Several hours after I posted this, Formencode merged the 
Python3 fix(es) and did a 2.0 release.  I guess I'm safe for now, and can 
migrate away at a more leisurely pace.

The big bug was on file uploads 
(https://github.com/formencode/formencode/issues/101), which broke under 
Python3.

I think the other tickers were all housekeeping.

On Friday, October 2, 2020 at 4:28:29 PM UTC-4 i...@laspilitas.com wrote:

> I guess I'm still using formencode too with python3 but maybe I just 
> worked around the bugs.  Do you know what is holding up the release?  Is it 
> for sure a dead-end?
>
> - Ian
>
> On Fri, Oct 2, 2020 at 1:20 PM Steve Piercy  wrote:
>
>> Deform uses Colander and Peppercorn.  Use Colander for schemas and 
>> validation.  There are no tutorials to migrate, but the demo should provide 
>> sufficient Colander schema examples for each Deform widget that you want.  
>> If you don't see something, ask!
>>
>> --steve
>>
>>
>> On 10/2/20 1:00 PM, 'Jonathan Vanasco' via pylons-discuss wrote:
>> > Thanks, Stev!
>> > 
>> > Deform is high on the list; I should have been more specific - I'm 
>> looking for any guidelines/tutorials/tools to migrate the code from 
>> Formencode to other libraries.  I have a lot of forms schemas/definitions 
>> to migrate.  I wrote my own validation layer, so I'm not too worried about 
>> migrating the code that interacts with forms.
>> > 
>> > FormEncode should my *last* Python2 library to support!  There is a 
>> longstanding bug on it file uploads breaking on Python3 . I've been using 
>> someone's stale PR as a patch for 2 years now, but that is just making 
>> everything too fragile so I try to keep all those apps running under 
>> Python2..
>> > 
>> > 
>> > On Friday, October 2, 2020 at 3:40:22 PM UTC-4 Steve Piercy wrote:
>> > 
>> > On 10/2/20 10:06 AM, 'Jonathan Vanasco' via pylons-discuss wrote:
>> > > Does anyone have tips/advice for migrating away from Formencode?
>> > 
>> > For server side rendering of forms, Deform is under active 
>> development and works under both Python 2 and 3.
>> > 
>> > Demo:
>> > https://deformdemo.pylonsproject.org/
>> > 
>> > GitHub:
>> > https://github.com/pylons/deform
>> > 
>> > Deform 3.0.0 will use Bootstrap 4 for its templates and drop Python 
>> 2 support, although it might still work under Python 2.
>> > https://github.com/Pylons/deform/milestone/3
>> > 
>> > --steve
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "pylons-discuss" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to pylons-discus...@googlegroups.com > pylons-discus...@googlegroups.com>.
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pylons-discuss/d0a0d404-f081-41f8-865f-b073ed17bc78n%40googlegroups.com
>>  
>> <
>> https://groups.google.com/d/msgid/pylons-discuss/d0a0d404-f081-41f8-865f-b073ed17bc78n%40googlegroups.com?utm_medium=email&utm_source=footer
>> >.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to pylons-discus...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pylons-discuss/6f0f2332-daa6-70a1-f148-2b32abdbb459%40gmail.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/1d1850a5-2e49-47f3-835d-c44a6595c60an%40googlegroups.com.


Re: [pylons-discuss] Help set up VSCode debugging + Pyramid App + docker

2020-10-05 Thread Steve Piercy
I have not had success using the PyCharm debugger with Docker.  Supposedly it 
is possible, but I have not found the magic combination of switches to flip and 
knobs to turn.

--steve


On 10/5/20 3:31 PM, Bach wrote:
> Thanks Steve I've had a good start following that youtube video and looking 
> through deformdemo (thanks for the pointer)
> But I can't get the *ptvsd* debugger to stop at breakpoints.. It's like it 
> attaches, but is not serving the app.. pserve is. So can't stop on 
> breakpoints.
> 
> Perhaps I need to move to debugpy  
> instead..
> 
> *Dockerfile*
> 
> 
> docker-compose.yml
> 
> 
> launch.js
> 
> 
> 
> 
> 
> On Monday, 5 October 2020 at 14:35:43 UTC+11 Steve Piercy wrote:
> 
> Check out deformdemo. It might help you get part of the way there.
> 
> https://github.com/Pylons/deformdemo
> 
> --steve
> 
> 
> On 10/4/20 8:20 PM, Bach wrote:
> > Hi everyone,
> >
> > been trying to setup Visual Studio Code to debug my Pyramid App running 
> inside a docker container.
> >
> > Does anyone have any sample files to share where you got that setup to 
> work:
> > - Dockerfile
> > - docker-compose.yml
> > - launch.jsonĀ 
> >
> > I initially setup an environment as described in this video, but the 
> example uses Flask and not pserve:
> > https://www.youtube.com/watch?v=b78Tg-YmJZI
> >
> > Any help or direction will be really appreciated!
> >
> > thanks
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/8980fc68-155f-4348-8109-9bd5a9e8b055n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/00b743eb-6cac-8e4b-6e4d-6e7d114bf75d%40gmail.com.


[pylons-discuss] Newbie Questions About Waitress Channels

2020-10-05 Thread Cooper Baird
I am starting to use Waitress, and I am trying to understand how channels 
and the backlog work, so forgive me for my ignorance if I'm not 
understanding this correctly. Let's say, hypothetically, that I am using 
all of the default settings (so 100 connection limit, 1024 backlog 
capacity, 4 threads, etc.). Let's say 100 users, all using HTTP/1.1 
clients, go to the site at once and begin browsing. Does this mean that any 
additional users (past the 100) that try to browse the site will hit an 
error or have a connection timeout since the 100 users fill up the channel 
capacity of 100 (and being HTTP/1.1 clients, all their requests will be 
served over the same channel, keeping it open)? If this is the case, then 
does that mean anyone past those initial 100 users will have to wait some 
time between 30s (cleanup interval) and 120s (channel timeout) to be able 
to browse? Or is this where the backlog comes in and channels can be reused 
somehow between users/clients? I apologize if that didn't all make sense. I 
can clarify anything that was unclear in my thought process/questioning.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/b9870007-07ea-4e25-bbd0-266e6d05bac2n%40googlegroups.com.


Re: [pylons-discuss] Newbie Questions About Waitress Channels

2020-10-05 Thread Michael Merickel
The connection limit dictates how many individual tcp connections waitress will 
handle at a time, and while those are alive (until client hangs up or idle 
channel timeout) no other connections will be made. The backlog is a signal to 
the OS to not outright reject connections even if waitress is not willing to 
handle them yet.

>From the list of connections, waitress will handle requests based on the 
>number of threads.

> On Oct 5, 2020, at 20:06, Cooper Baird  wrote:
> 
> I am starting to use Waitress, and I am trying to understand how channels and 
> the backlog work, so forgive me for my ignorance if I'm not understanding 
> this correctly. Let's say, hypothetically, that I am using all of the default 
> settings (so 100 connection limit, 1024 backlog capacity, 4 threads, etc.). 
> Let's say 100 users, all using HTTP/1.1 clients, go to the site at once and 
> begin browsing. Does this mean that any additional users (past the 100) that 
> try to browse the site will hit an error or have a connection timeout since 
> the 100 users fill up the channel capacity of 100 (and being HTTP/1.1 
> clients, all their requests will be served over the same channel, keeping it 
> open)? If this is the case, then does that mean anyone past those initial 100 
> users will have to wait some time between 30s (cleanup interval) and 120s 
> (channel timeout) to be able to browse? Or is this where the backlog comes in 
> and channels can be reused somehow between users/clients? I apologize if that 
> didn't all make sense. I can clarify anything that was unclear in my thought 
> process/questioning.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/b9870007-07ea-4e25-bbd0-266e6d05bac2n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/AD7DAE51-F0DE-4B2A-AA20-D8F2772DCCF2%40gmail.com.


Re: [pylons-discuss] Newbie Questions About Waitress Channels

2020-10-05 Thread Cooper Baird
Awesome. That clarifies my questions. Thanks! I'm trying to get a sense as 
to what I should set connection limit on a heroku 1x dyno. I ran ulimit -a 
within the dyno using heroku run and saw a value of 1 for the max # of 
file descriptors. 100 does seem very conservative, as mentioned in the 
documentation. I don't want to set this value to something unsafe, but I 
would like to maximize the number of open connections per dyno. Do you have 
any advice in what I should set that value? I don't anticipate needing to 
support > 100 connections at once super soon, but would like to plan ahead.

On Monday, October 5, 2020 at 9:23:25 PM UTC-4 mmer...@gmail.com wrote:

> The connection limit dictates how many individual tcp connections waitress 
> will handle at a time, and while those are alive (until client hangs up or 
> idle channel timeout) no other connections will be made. The backlog is a 
> signal to the OS to not outright reject connections even if waitress is not 
> willing to handle them yet.
>
> From the list of connections, waitress will handle requests based on the 
> number of threads.
>
> On Oct 5, 2020, at 20:06, Cooper Baird  wrote:
>
> I am starting to use Waitress, and I am trying to understand how channels 
> and the backlog work, so forgive me for my ignorance if I'm not 
> understanding this correctly. Let's say, hypothetically, that I am using 
> all of the default settings (so 100 connection limit, 1024 backlog 
> capacity, 4 threads, etc.). Let's say 100 users, all using HTTP/1.1 
> clients, go to the site at once and begin browsing. Does this mean that any 
> additional users (past the 100) that try to browse the site will hit an 
> error or have a connection timeout since the 100 users fill up the channel 
> capacity of 100 (and being HTTP/1.1 clients, all their requests will be 
> served over the same channel, keeping it open)? If this is the case, then 
> does that mean anyone past those initial 100 users will have to wait some 
> time between 30s (cleanup interval) and 120s (channel timeout) to be able 
> to browse? Or is this where the backlog comes in and channels can be reused 
> somehow between users/clients? I apologize if that didn't all make sense. I 
> can clarify anything that was unclear in my thought process/questioning. 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discus...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/b9870007-07ea-4e25-bbd0-266e6d05bac2n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/2b78006d-50f1-4acb-a7e7-4d722e372244n%40googlegroups.com.


Re: [pylons-discuss] Newbie Questions About Waitress Channels

2020-10-05 Thread Michael Merickel
The only default I've really changed on waitress in most apps I've written has 
been the number of threads. On Heroku I also configure waitress to understand 
the forwarding headers (see trusted_proxy docs) so that client data shows up 
properly in the WSGI app.

I would not worry about these issues unless you feel your site is susceptible 
to specific types of abuse (DDOS, slowloris, etc) - at which point I would 
recommend you look at tuning a proxy like nginx in front of basically any WSGI 
server to buffer / filter clients before they hit your backend.

> On Oct 5, 2020, at 20:34, Cooper Baird  wrote:
> 
> Awesome. That clarifies my questions. Thanks! I'm trying to get a sense as to 
> what I should set connection limit on a heroku 1x dyno. I ran ulimit -a 
> within the dyno using heroku run and saw a value of 1 for the max # of 
> file descriptors. 100 does seem very conservative, as mentioned in the 
> documentation. I don't want to set this value to something unsafe, but I 
> would like to maximize the number of open connections per dyno. Do you have 
> any advice in what I should set that value? I don't anticipate needing to 
> support > 100 connections at once super soon, but would like to plan ahead.
> 
> On Monday, October 5, 2020 at 9:23:25 PM UTC-4 mmer...@gmail.com wrote:
> The connection limit dictates how many individual tcp connections waitress 
> will handle at a time, and while those are alive (until client hangs up or 
> idle channel timeout) no other connections will be made. The backlog is a 
> signal to the OS to not outright reject connections even if waitress is not 
> willing to handle them yet.
> 
> From the list of connections, waitress will handle requests based on the 
> number of threads.
> 
> 
>> On Oct 5, 2020, at 20:06, Cooper Baird > > wrote:
>> 
> 
>> I am starting to use Waitress, and I am trying to understand how channels 
>> and the backlog work, so forgive me for my ignorance if I'm not 
>> understanding this correctly. Let's say, hypothetically, that I am using all 
>> of the default settings (so 100 connection limit, 1024 backlog capacity, 4 
>> threads, etc.). Let's say 100 users, all using HTTP/1.1 clients, go to the 
>> site at once and begin browsing. Does this mean that any additional users 
>> (past the 100) that try to browse the site will hit an error or have a 
>> connection timeout since the 100 users fill up the channel capacity of 100 
>> (and being HTTP/1.1 clients, all their requests will be served over the same 
>> channel, keeping it open)? If this is the case, then does that mean anyone 
>> past those initial 100 users will have to wait some time between 30s 
>> (cleanup interval) and 120s (channel timeout) to be able to browse? Or is 
>> this where the backlog comes in and channels can be reused somehow between 
>> users/clients? I apologize if that didn't all make sense. I can clarify 
>> anything that was unclear in my thought process/questioning.
>> 
> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to pylons-discus...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pylons-discuss/b9870007-07ea-4e25-bbd0-266e6d05bac2n%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/2b78006d-50f1-4acb-a7e7-4d722e372244n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/DC31D835-6859-47E7-8661-E107D210CE31%40gmail.com.


Re: [pylons-discuss] Newbie Questions About Waitress Channels

2020-10-05 Thread Cooper Baird
I gotcha. Yeah I'm just trying to get a sense of how high of a value for
connection-limit is too high for the platform, but I get that it depends on
other things going on in the application too (other things that are using
the file descriptors). I just fear making it too high, so I guess I'll go
with the default 100 for the time being.

On Mon, Oct 5, 2020 at 9:41 PM Michael Merickel  wrote:

> The only default I've really changed on waitress in most apps I've written
> has been the number of threads. On Heroku I also configure waitress to
> understand the forwarding headers (see trusted_proxy docs) so that client
> data shows up properly in the WSGI app.
>
> I would not worry about these issues unless you feel your site is
> susceptible to specific types of abuse (DDOS, slowloris, etc) - at which
> point I would recommend you look at tuning a proxy like nginx in front of
> basically any WSGI server to buffer / filter clients before they hit your
> backend.
>
> On Oct 5, 2020, at 20:34, Cooper Baird  wrote:
>
> Awesome. That clarifies my questions. Thanks! I'm trying to get a sense as
> to what I should set connection limit on a heroku 1x dyno. I ran ulimit -a
> within the dyno using heroku run and saw a value of 1 for the max # of
> file descriptors. 100 does seem very conservative, as mentioned in the
> documentation. I don't want to set this value to something unsafe, but I
> would like to maximize the number of open connections per dyno. Do you have
> any advice in what I should set that value? I don't anticipate needing to
> support > 100 connections at once super soon, but would like to plan ahead.
>
> On Monday, October 5, 2020 at 9:23:25 PM UTC-4 mmer...@gmail.com wrote:
>
>> The connection limit dictates how many individual tcp connections
>> waitress will handle at a time, and while those are alive (until client
>> hangs up or idle channel timeout) no other connections will be made. The
>> backlog is a signal to the OS to not outright reject connections even if
>> waitress is not willing to handle them yet.
>>
>> From the list of connections, waitress will handle requests based on the
>> number of threads.
>>
>> On Oct 5, 2020, at 20:06, Cooper Baird  wrote:
>>
>> I am starting to use Waitress, and I am trying to understand how channels
>> and the backlog work, so forgive me for my ignorance if I'm not
>> understanding this correctly. Let's say, hypothetically, that I am using
>> all of the default settings (so 100 connection limit, 1024 backlog
>> capacity, 4 threads, etc.). Let's say 100 users, all using HTTP/1.1
>> clients, go to the site at once and begin browsing. Does this mean that any
>> additional users (past the 100) that try to browse the site will hit an
>> error or have a connection timeout since the 100 users fill up the channel
>> capacity of 100 (and being HTTP/1.1 clients, all their requests will be
>> served over the same channel, keeping it open)? If this is the case, then
>> does that mean anyone past those initial 100 users will have to wait some
>> time between 30s (cleanup interval) and 120s (channel timeout) to be able
>> to browse? Or is this where the backlog comes in and channels can be reused
>> somehow between users/clients? I apologize if that didn't all make sense. I
>> can clarify anything that was unclear in my thought process/questioning.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pylons-discus...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/pylons-discuss/b9870007-07ea-4e25-bbd0-266e6d05bac2n%40googlegroups.com
>> 
>> .
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/2b78006d-50f1-4acb-a7e7-4d722e372244n%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "pylons-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pylons-discuss/LO8TsTlzOfY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pylons-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/DC31D835-6859-47E7-8661-E107D210CE31%40gmail.com
> 

Re: [pylons-discuss] migrating away from formencode?

2020-10-05 Thread Mike Orr
I'm using Formencode 1.3.1. My application switched to Python 3 in
2017 and I haven't had any problems with Formencode. It has two file
uploads, one with a form, and if I submit it without a file I get the
error message "Please provide only one value" mentioned in the issue.
This is not a big deal in my use case. Now that Formencode 2 is out
I'll upgrade to it.

On Mon, Oct 5, 2020 at 7:34 AM 'Jonathan Vanasco' via pylons-discuss
 wrote:
>
> Talk about timing. Several hours after I posted this, Formencode merged the 
> Python3 fix(es) and did a 2.0 release.  I guess I'm safe for now, and can 
> migrate away at a more leisurely pace.
>
> The big bug was on file uploads 
> (https://github.com/formencode/formencode/issues/101), which broke under 
> Python3.
>
> I think the other tickers were all housekeeping.
>
> On Friday, October 2, 2020 at 4:28:29 PM UTC-4 i...@laspilitas.com wrote:
>>
>> I guess I'm still using formencode too with python3 but maybe I just worked 
>> around the bugs.  Do you know what is holding up the release?  Is it for 
>> sure a dead-end?
>>
>> - Ian
>>
>> On Fri, Oct 2, 2020 at 1:20 PM Steve Piercy  wrote:
>>>
>>> Deform uses Colander and Peppercorn.  Use Colander for schemas and 
>>> validation.  There are no tutorials to migrate, but the demo should provide 
>>> sufficient Colander schema examples for each Deform widget that you want.  
>>> If you don't see something, ask!
>>>
>>> --steve
>>>
>>>
>>> On 10/2/20 1:00 PM, 'Jonathan Vanasco' via pylons-discuss wrote:
>>> > Thanks, Stev!
>>> >
>>> > Deform is high on the list; I should have been more specific - I'm 
>>> > looking for any guidelines/tutorials/tools to migrate the code from 
>>> > Formencode to other libraries.  I have a lot of forms schemas/definitions 
>>> > to migrate.  I wrote my own validation layer, so I'm not too worried 
>>> > about migrating the code that interacts with forms.
>>> >
>>> > FormEncode should my *last* Python2 library to support!  There is a 
>>> > longstanding bug on it file uploads breaking on Python3 . I've been using 
>>> > someone's stale PR as a patch for 2 years now, but that is just making 
>>> > everything too fragile so I try to keep all those apps running under 
>>> > Python2..
>>> >
>>> >
>>> > On Friday, October 2, 2020 at 3:40:22 PM UTC-4 Steve Piercy wrote:
>>> >
>>> > On 10/2/20 10:06 AM, 'Jonathan Vanasco' via pylons-discuss wrote:
>>> > > Does anyone have tips/advice for migrating away from Formencode?
>>> >
>>> > For server side rendering of forms, Deform is under active 
>>> > development and works under both Python 2 and 3.
>>> >
>>> > Demo:
>>> > https://deformdemo.pylonsproject.org/
>>> >
>>> > GitHub:
>>> > https://github.com/pylons/deform
>>> >
>>> > Deform 3.0.0 will use Bootstrap 4 for its templates and drop Python 2 
>>> > support, although it might still work under Python 2.
>>> > https://github.com/Pylons/deform/milestone/3
>>> >
>>> > --steve
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "pylons-discuss" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send an 
>>> > email to pylons-discus...@googlegroups.com 
>>> > .
>>> > To view this discussion on the web visit 
>>> > https://groups.google.com/d/msgid/pylons-discuss/d0a0d404-f081-41f8-865f-b073ed17bc78n%40googlegroups.com
>>> >  
>>> > .
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "pylons-discuss" group.
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to pylons-discus...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/pylons-discuss/6f0f2332-daa6-70a1-f148-2b32abdbb459%40gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/1d1850a5-2e49-47f3-835d-c44a6595c60an%40googlegroups.com.



-- 
Mike Orr 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DupMoa-TFmtvg0H3yzDGt3%3D9-S7r3L-0%2BWNTtmRjOkxKMA%40mail.gmail.com.


Re: [pylons-discuss] Help set up VSCode debugging + Pyramid App + docker

2020-10-05 Thread Bach
Thanks a lot Michael that's perfect!!
I have removed *--reload* and everything worked as expected!

now onto trying your example to get *--reload *working.
Thanks again guys I really appreciate.

Bach

On Tuesday, 6 October 2020 at 10:48:10 UTC+11 mmer...@gmail.com wrote:

> The issue that makes pserve different from Marcel Demper's example is that 
> `pserve --reload` uses a multiprocess model (via hupper) to spawn your code 
> in a subprocess. If you run without `--reload` things will work as expected.
>
> If you want `--reload` to work, you will need to run ptvsd inside your 
> process instead of externally via something like:
>
> if I_SHOULD_ATTACH_TO_VSCODE:
> try:
> import ptvsd
> except ModuleNotFoundError:
> raise RuntimeError('ptvsd is not installed')
>
> print("Waiting for debugger attach ...", file=sys.stderr)
> ptvsd.enable_attach(address=('0.0.0.0', 5678), 
> redirect_output=True)
> ptvsd.wait_for_attach()
>
> You could run this inside your __init__.py or somewhere else that is 
> executed inside the subprocess.
>
> - Michael
>
> On Oct 5, 2020, at 17:31, Bach  wrote:
>
> Thanks Steve I've had a good start following that youtube video and 
> looking through deformdemo (thanks for the pointer)
> But I can't get the *ptvsd* debugger to stop at breakpoints.. It's like 
> it attaches, but is not serving the app.. pserve is. So can't stop on 
> breakpoints.
>
> Perhaps I need to move to debugpy  
> instead..
>
> *Dockerfile*
>
>
> docker-compose.yml
>
>
> launch.js
>
>
>
>
>
> On Monday, 5 October 2020 at 14:35:43 UTC+11 Steve Piercy wrote:
>
>> Check out deformdemo. It might help you get part of the way there. 
>>
>> https://github.com/Pylons/deformdemo 
>>
>> --steve 
>>
>>
>> On 10/4/20 8:20 PM, Bach wrote: 
>> > Hi everyone, 
>> > 
>> > been trying to setup Visual Studio Code to debug my Pyramid App running 
>> inside a docker container. 
>> > 
>> > Does anyone have any sample files to share where you got that setup to 
>> work: 
>> > - Dockerfile 
>> > - docker-compose.yml 
>> > - launch.json  
>> > 
>> > I initially setup an environment as described in this video, but the 
>> example uses Flask and not pserve: 
>> > https://www.youtube.com/watch?v=b78Tg-YmJZI 
>> > 
>> > Any help or direction will be really appreciated! 
>> > 
>> > thanks 
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discus...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/8980fc68-155f-4348-8109-9bd5a9e8b055n%40googlegroups.com
>  
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/546b6ed5-a65f-4d01-8bc3-30f64940e7f2n%40googlegroups.com.