Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow bypassing log setup in the API use #1896

Closed
whg517 opened this issue Jul 10, 2020 · 2 comments · Fixed by #1904
Closed

Allow bypassing log setup in the API use #1896

whg517 opened this issue Jul 10, 2020 · 2 comments · Fixed by #1904

Comments

@whg517
Copy link

whg517 commented Jul 10, 2020

In my code, I wanted to create the virtual environment manually by calling def cli_run(args, options=None): , but when I ran it, I found that my log could not be obtained. Through searching, I found that you clarified the root log in the code, which made me unable to use my log object after running.

I wonder what you're doing this for? Do you use custom Log objects instead of cleaning the root Log ?

LOGGER.setLevel(logging.NOTSET)

def _clean_handlers(log):
for log_handler in list(log.handlers): # remove handlers of libraries
log.removeHandler(log_handler)

I now can do a patch or duplicate the code of cli_run, session_via_cli, and build_parser and remove the line _do_report_setup .

@gaborbernat gaborbernat changed the title Why do you want to clear the root logger ??? Why do you want to clear the root logger Jul 10, 2020
@gaborbernat gaborbernat changed the title Why do you want to clear the root logger Allow bypassing log setup in the API use Jul 10, 2020
@gaborbernat
Copy link
Contributor

We're using our own log reporters to guarantee output, without clearing the logs we might generate our output in unwanted locations. For your use case, I think would be helpful to have an option to disable log setup. Though now one might argue that the output controlling flags would be unrespected.

@whg517
Copy link
Author

whg517 commented Jul 11, 2020

Thank you for your reply. I understand what you mean.

If you want to avoid this, I think you can readjust the invocation logic to leave the interfaces for third-party applications. Not as tightly coupled

In fact, I think the upper layer of the function module should be the CMD call layer in the design. When other projects need to use it, the corresponding function module can be directly used.

Of course, given that Virtualenv is already a mature scenario, I've only been thinking about it by looking at its source code, perhaps prematurely. Please don't mind.

In my current practice, I copied three methods cli_run , session_via_cli and build_parser from virtualenv/run/__init__.py , then deleted _do_report_setup(parser, args) in build_parser method.

You can also do this through a Subprocess call, but it may take more work on process control and exception handling.

Of course I wish there was a more elegant way to solve this problem. Thank you again.

@pypa pypa locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants