-
Notifications
You must be signed in to change notification settings - Fork 8
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
add dagit to setup.py #22
Conversation
Your pull request is automatically being deployed to Dagster Cloud.
|
setup.py
Outdated
@@ -5,6 +5,7 @@ | |||
name="my_dagster_project", | |||
packages=find_packages(exclude=["my_dagster_project_tests"]), | |||
install_requires=[ | |||
"dagit", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
other examples include dagit
in extras_require=
, e.g. https://github.com/dagster-io/dagster/blob/master/examples/assets_dbt_python/setup.py#L18, and then in the readme, we recommend using pip install -e ".[dev]"
to install deps which then will install dagit locally (see readme here)
including dagit
in the default install_requires
would slow down the prod build, because dagster cloud or other deployment set up won't need to install dagit and dagit is a heavy dependency to install. so we separate dagit to extra installs
Maybe we should keep the quickstart as minimal as possible? What prompted this is that during implementation calls its often nice to show off running dagit for local dev but it does seem like theres other things we'd want to add as well to fully flush out a realistic starter project? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a minimal change that is useful for quickstart users. One minor comment, but this looks great. Thanks Joe!
README.md
Outdated
@@ -26,3 +26,19 @@ Set up secrets on your newly created repository by navigating to the `Settings` | |||
## Verify Builds are Successful | |||
|
|||
At this point, the Workflow should complete successfully. If builds are failing, ensure that your secrets are properly set and that your deployment has finished activating. | |||
|
|||
## Developing Locally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of "Developing Locally" I'd call this "Next Steps" and include a preamble like:
Now that your GitHub repository is setup with CI/CD to deploy to Dagster Cloud, you can add your own Dagster code. To run this project locally...
And then at the end maybe something like:
You can also copy any existing Dagster examples or quickstart projects into this GitHub repository.
being able to develop locally is a really powerful feature that we should be encouraging quickstart users to use.