update changes, docs

• switch tests to pass in overriding remove_path_fn instead of using mocks

• rename fn_name

black

• add python package load-from arg

On reflection, I think the only reason that person in #general hit that case (CWD-dependent imports) was because we were manually adding the working directory to the path in python_modules/dagster/dagster/cli/__init__.py.

clean up, simplify path manipulation, add more comments

check against ImportError instead, to support py27

add mock to stub out sys.path replacements

remove ability to load modules resolved by local directory

• add test, address schema query

• resolve introspection query

• comments, changes

makes sense to me... will let @schrockn and @bengotow also weigh in. should we also rename the component RepositoryPicker, etc?

This looks great. We should fix the cursor typo, but o.w. lgtm

• split out directory-aware module code pointer

• remove default working directory, resolve working_directory relative to workspace.yaml

Yeah, I think we need to somehow force a schedule reconcile upon version update.

Also, yes, the defaults are the part that I'm most unsure about...

I'm not sure about changing the file-based code pointer... What's the error case we're handling there? I guess the name working_directory could mean that it should allow relative paths there...

• add working directory to origin repo args

I made sure we had a test for loading relative modules, but found it hard to test some of the other flows involving PYTHONPATH...

nice

Can also approve this if you want this to be separate diffs....

I think for completeness, you probably want to be able to query this off of the preset in graphql in the ConfigEditorConfigPicker, similar to the partition tags (except no need to make the call over the API). This should pre-fill the tag section in the playground.

comments

fix tests

trailing comma

restored wrapping *ErrorData namedtuples

update

What tests were failing? Just trying to get a sense of when this would pop up...

update

feel free to comment with your own changes and will add them in...

• split out error class

In D3570#93359, @schrockn wrote:

I know its a pain but I do think its much clearer/safer if we return different types for error cases rather than having all the properties be optional

Okay. I *think* this is causing some confusion because it's easy to confuse attempts with runs and execution time with partition date. I think something that looks more like a streaming logfile that people need to click into to debug would be more useful.