hey, I'm trying out the new core api and interested in the intended usage. context: our pipelines are usually separated into folders with their run_configs and schedules (which we quite like as everything is contained in a single dir) and they are imported to the dagster repo. the problem with this, that we need to add the same modes and tags to every solid and pipeline, this is where

<http://graph.to|graph.to>_job

could help I believe. is there any way to keep

run_configs

schedules

close to the

graphs/pipelines

and

resources

tags

close to

repos

like:

[<http://g.to|g.to>_job(resources, tags..) for g in graphs]

what's the intended way to organise multiple pipelines + run_configs?

hey @szalai1 - good question.

[<http://g.to|g.to>_job(resources, tags..) for g in graphs]

is definitely an intended pattern. it does get tricky when you want to include schedules and run config. if the config is just for the graph and not for the resources, you can do

graph.configured(...)

to create a graph with the config curried in. and schedules need to point to a job, so they can't be constructed until after the

to_job

invocation, which makes it somewhat awkward. we could potentially go back to allowing string pointers - it seems like that might be preferable in your situation? if it would be helpful for you, you and I could find some time to go over the code on a video call and look at options?

yes,

configured

can solve this. thanks. I will try that out and let you know it I have questions. --- we are also planning to go over all of our old pipelines and refactor them to use

graphs

and

io_managers

so we would like some structure that makes sense and easy to manage in the long-run too. I'm sure we will have questions 🙂 thank again