-
Notifications
You must be signed in to change notification settings - Fork 148
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
Document first-time developer setup, add conda option #2083
Document first-time developer setup, add conda option #2083
Conversation
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.
Thanks very much this is great. A few minor comments.
I going to ask Tom to look at this too, just to get a second pair of eyes on a couple parts of this, but overall, very happy with how it's looking. A big improvement!
|
||
When making changes to Splink, there are a number of common operations that developers need to perform. The guides below lay out some of these common operations, and provides scripts to automate these processes. These include: | ||
|
||
* [Building a Virtual Environment](./changing_splink/building_env_locally.md) - to replicate the conditions when Splink is installed by users. | ||
* [Linting and Formatting](./changing_splink/lint_and_format.md) - to ensure consistent code style and to reformat code, where possible. |
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.
Should the first bullet in this list point to the new quickstart page?
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.
I don't see a ton of utility in this list. "Linting and Formatting" and "Testing" are already linked in the contributor's guide section about contributing code (the only type of contribution to which they are relevant). Likewise with building the docs locally.
Releasing a new package version is nice to have documented, but calling it out for new contributors seems unnecessary -- they almost certainly wouldn't have the permissions to do this.
And contributing to the blog seems like perhaps it should just be its own section in the contributor's guide.
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.
Yeah agreed, in fact the whole page feels unnecessarily repetitious and could probably be dropped entirely.
We probably need to review it separately. Just want to make sure the quickstart is as obvious as possible - feel free to do whatever you think's best!
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.
Sounds good and happy to help with that. I think in this PR I won't put the quickstart in the list since it is not a "common operation that developers need to perform."
@ThomasHepworth would you mind having a quick look at this? I've gone through in detail, but I think it'd be good to get a second pair of eyes specifically on docs/dev_guides/changing_splink/development_quickstart.md I have:
So I think it's just a sense check that's needed |
Thank you for doing all of this! It's really useful for us to get input and feedback from people coming to Splink from outside our bubble. I'll check it over now and leave a few comments. |
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.
Thanks again Zeb! This is a great step forward in this department.
See a few minor comments and discussion points below. I've also had a word with Robin espousing the use of conda and I believe he's going to comment on that side of things.
Tom and I had a chat about this earlier. We both agree it's a great improvement. There's one aspect both of us picked up on: Whilst the quickstart page contains options for both conda and non-conda, the way its layed out implicitly suggests that conda is the recommended option. This didn't feel quite right because none of the core dev team use conda. You'll see I've done a draft PR to move things around a little and include a (hopefully not too controversial) line on whether re recommend conda or not. |
Co-authored-by: Robin Linacre <robin.linacre@digital.justice.gov.uk>
Co-authored-by: Robin Linacre <robin.linacre@digital.justice.gov.uk>
Co-authored by: Tom Hepworth <45356472+ThomasHepworth@users.noreply.github.com>
Co-authored by: Robin Linacre <robin.linacre@digital.justice.gov.uk>
…hub.com/zmbc/splink into docs/onboarding-development-environment
Thank you both for your reviews! I believe I've addressed all the comments now. See my comments on the de-emphasize conda PR -- if they look good to you, I can merge those changes into this branch. |
Co-authored-by: Zeb Burke-Conte <zmbc@users.noreply.github.com>
Co-authored-by: Zeb Burke-Conte <zmbc@users.noreply.github.com>
Thanks @zmbc! I've responded to your comments on the de-emphasize conda PR Happy for you to merge it in and after that we should be good to go. Thanks again! |
@ThomasHepworth I think this is just waiting for follow-up on your two unresolved comments above. Once we get those ironed out, it should be good to go! |
@zmbc after you've tweaked the Thanks again for your work on this! |
Addressed the comments, and I believe my changes should now fix the CI failures, except that the mkdocs CI seems to not like that this PR is from a fork. |
Type of PR
Is your Pull Request linked to an existing Issue or Pull Request?
#2019
Give a brief description for the solution you have provided
More or less followed the outline I gave in #2019 (reply in thread), except I reordered some things.
PR Checklist