Disable this somehow for production

[josephmancuso]

This does a lot of calculations so we need to be able to disable this somehow.

For example, this should really only be enforced during development and then when you move to a production environment it should be disabled. We don't want to enforce any checks on production environments.

[psyonara]

Could a check on settings.DEBUG suffice for this?

[josephmancuso]

It could for Django right? Is there a way to check for global settings on any python project? I don’t really want to do 10 checks for 10 different frameworks way of setting debug modes ..🤔

[psyonara]

Haha, sorry, my thinking always defaults to Django. Of course, it would need something that is framework agnostic. Thinking about it some more now, I can only see this working by checking an environment variable. Would you say that it needs to be disabled by default, and then the developer sets a env var to specifically enable it in their development environment? Then the default is already correct for production environments, and the developer doesn't need to worry about making sure it's off in production. But that would also require one extra step to get it set up when you start to implement it during development.

[josephmancuso]

yeah it should definitely be enabled by default but an environment variable is actually a really good idea. something like ENABLE_INTERFACES and we can turn it on or off (even in development)

[psyonara]

Cool, I could take a look at this then, if you like. I should be able to make some time for it this week.

[josephmancuso]

sounds good to me 👍 let me know if you need help

[psyonara]

@josephmancuso Will the new environment variable completely replace the check for application.DEBUG, or do you want to keep that in there, and use it in combination with ENABLE_INTERFACES?

[josephmancuso]

ummmmmmmm. yes. I'd like sort of "first class support" for Masonite but it's fine.

So yes replace that check if the ENABLE_INTERFACES check.

Keep in mind though that I'm pretty sure you need to do a string check if it's true. Environment variables will always be strings.

[psyonara]

Actually I think Masonite support can be preserved. So if it's being used as part of Masonite, and the new env var is either not defined, or marked as enabled, we can keep the DEBUG check. So then Masonite users will not have to do anything additional.

Anyway, will give it a try, and see what I can come up with. :)

[josephmancuso]

Sounds good to me but it will be a little tricky because that check needs to be outside of the try catch block I would think

[psyonara]

I have some ideas. :)