Hi Dagster ninjas! I have a simple question that I don't seem to see documented. I just want my SOLIDs to output ANYTHING in an imported python module's print() to the console. I know I can do context.log.info("Some text") to output it to Dagster console. But, I just want to directly pipe any time the python code says print()--> to---> context.log.info(). I'm not concerned with masking the spew, or re-writing all previously used modules into the new format. Help please?!

This isn't a direct answer to your question, but you should be able to get to standard out via one of the log lines in the event log. It looks like this:

HI sandy. Thanks for your reply. Um, maybe STDOUT is not what I need. When I look at the

Raw Step Out

, it's blank. I literally just need whatever is output when I type

print()

in a python module I've imported and used in a dagster

@solid

. I think some modules (like Autodesk Maya's python API) re-direct their prints to STDOUT, but I can't depend on that behavior. So, more specifically, is there something I need to do with dagster to redirect, or expose, or whatever the terminology is - to just make it so whenever I have typed

print('some text')

in an imported module, I get the same result as

<http://context.log.info|context.log.info>('some text')

in my

@solid

usage. Does that make sense? I don't know if I'm being clear...

Python automatically sends any string that’s passed to print to stdout, so print statements should automatically be showing up in the raw step output. Any chance you’d be able to share a code example that reproduces the problem? As for redirecting to context.log, there’s likely a way to hack it using contextlib.redirect_stdout. Apologies that I don’t have a more specific answer.

Hi dagster team, we’d have a question in the same direction (log-output). As dagster capture all output from native logger (context.log.*) and also stdout, these outputs are landing directly in dagster and not anywhere on the console. We have Kubernetes running with ELK with outputs directly appended to Elastic-Search and Kibana. Now because ob above scenario, the logs are in dagster but not in our Kibana/Elastic-Search. Would you have a hint if we’d want to keep the output in dagster of course, but also log it to the console? Can we somewhere easily do that or do we need to write our own logger?

the raw logs should be in the pod logs as well - we mirror them back to stdout/stderr while we are capturing them

Thank you guys for your help. For some reason, I'm still not able to see

print()

statements in the dagit : playground or runs console output views(not sure of their actual name, but the views you see in dagit as it's running a pipeline.). Right now, I have a work-around where I just have to code up

<http://context.log.info|context.log.info>()

into the @solid function any time I want to print something for my users to see there. You see, I intend to share a dagit link to my users to expose launching pipelines and viewing the run results. So, they will see dagit in their browser, but have no access to the command shell running on my PC serving out dagit. So, if it doesn't print to the dagit UI, it's invisible to my users( or they could expand that

raw step output

, as you pointed out ...but so far, for me, it's blank). Maybe I have something wrong on my end. I hope this thread helps others. I'm kind of abandoning this as I need to move on, but it's not really resolved, for me. The reason this is important is: 1. I will probably want to leverage other, previously built, internal, python modules in my @solids. Those modules (built for python standalone) often print up very useful information as they go. It's unreasonable to have to re-write those modules inside of a @solid, because we already have a somewhat robust little library, and why duplicate everything when you can just import it? Seems very un-pythonic, or bad project organization practice to not be able to re-use those because you can't depend on their print() output. 2. I may not have access to re-write those python modules. They are used by other teams, and I may not be able to re-configure their signature to play nicer with dagster-specific features. So, I have to operate by 'if it works in python standalone, it should be able to work by import in dagster' rule. For now, I guess I have to just re-build each feature inside an @solid. I guess I have to replace imported non-standard libraries with custom @solids, basically copy-paste the code from my module to the inside of the @solid function, and change any

print()

statement to

<http://contex.log.info|contex.log.info>()

. This will be annoying, but I guess this ensures reliable behavior in dagit, and maybe gives me some option to do something custom for dagit. Correct me if I'm wrong. Hope this helps others.