This eliminates the very unpleasant ImportError: attempted relative import with no known parent package which, horribly, in the status quo ante appeared only when targeting a file for execution (e.g., dagit -f -n) that was in fact doing valid relative imports in a valid package. I suspect our users also hit this error and, like most of us most of the time, don't understand that it means they should be using dagit -m instead.
• schrockn alangenfeld • themissinghlink
Is there any way to construct some tests that showcase expected behaviors under the different scenarios here? I'm a little nervous about ensuring the different logic paths are correct
I'd like us to consider a more constrained approach, where we disallow loading from a file in a module context. I think with a good error message this is fine. (We could even print out the exact command.) This imposes the requirement on the user that they have the module installed, but I believe this is reasonable requirement that would dramatically simplify things.
I really think the requested changes would make the local dev experience much more onerous -- essentially, we're saying to users, either make your local dev env pip installable, or edit your python path manually every time you want to work on something new. FWIW, I am probably going to keep this changeset around locally for my own convenience, even if we don't land it.
Adding @themissinghlink because he hit this same issue locally and concluded that the CLI tools didn't work.
I'm a bit confused re: the comment on altering the path. From my perspective what I suggesting supports two use cases:
- Loading by module if the code is in a module.
- Loading by file if the code is in a bare file.
If you are trying to load by file in a module context, it would clearly communicate an error (perhaps even with the exact command to launch in the error message).
Where do you have to alter the path?