-
Notifications
You must be signed in to change notification settings - Fork 53
Add section on tooling #18
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
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.
@saulshanabrook Nice draft! Left some comments (notably, need to turn on IDE spellcheck ;)).
I think a larger question concerns how much implementation detail we actually want to describe, given its likelihood to change and a desire to minimize spec "noise".
Thanks @kgryte!
Yes, need to do this! Was just writing in my browser...
I took out some of the details, but I do think this will still need to evolve a bit as our data process continues to evolve. |
(sidenote: the aspects that are too detailed here, might be interesting to move to the python-record-api repo itself? Eg to its README or docs) |
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 @saulshanabrook, this looks like a good start to me.
Regarding structure, we have two tooling topics, so we need to decide whether to keep the structure of sections as it is now, or to split into the array-api-comparison
and python-record-api
parts right after the summary. I think I'd favour the latter.
There's probably a bit missing about how we use the data for decision making. That should come at the end I think, after it's clear to the reader what data is produced.
Also, can you wrap to 80 char lines? That will make it much easier to review.
That makes some sense. I haven't started this yet.
I added a few sentences on this, but wasn't very specific.
Sure, wrapped. |
@rgommers This should be ready for another round of reviews. |
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.
Looks good to me!
Co-authored-by: Athan <[email protected]>
01ef7e2
to
69f0231
Compare
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.
LGTM too, just pushed a couple of tiny textual fixes. The story flows very well here, and the section ends up being nice and concise.
I wrote up some of the motivation and details behind the record-api tooling.
Happy to expand or reorganize from any feedback.
I didn't add many details about how the
array-api-comparison
works. @kgryte feel free to lemme know what I should add there, or add that in a follow up.