home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

5 rows where issue = 1404894283 sorted by updated_at descending

✖
✖

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 2

  • max-sixty 3
  • keewis 2

issue 1

  • use a hook to synchronize the versions of `black` · 5 ✖

author_association 1

  • MEMBER 5
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1275128173 https://github.com/pydata/xarray/pull/7153#issuecomment-1275128173 https://api.github.com/repos/pydata/xarray/issues/7153 IC_kwDOAMm_X85MAOlt keewis 14808389 2022-10-11T18:48:01Z 2022-10-11T19:26:48Z MEMBER

yeah, external dependency management is a bit of a pain with pre-commit, and unfortunately that is unlikely to change.

Does pre-commit support additional_dependencies defined by the hook?

it does not complain, but I don't think it does anything with that (though I didn't verify). Also, I don't really want to issue basically empty releases just for pre-commit (even though technically feasible), so the only option I can see is indeed the status quo.

Edit: actually, no, it does make use of additional_dependencies. There's a NamedTuple that will contain all that information, and setting something in .pre-commit-config.yaml will overwrite the default values set in the hook definition.

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  use a hook to synchronize the versions of `black` 1404894283
1275136361 https://github.com/pydata/xarray/pull/7153#issuecomment-1275136361 https://api.github.com/repos/pydata/xarray/issues/7153 IC_kwDOAMm_X85MAQlp max-sixty 5635139 2022-10-11T18:54:58Z 2022-10-11T18:54:58Z MEMBER

it does not complain, but I don't think it does anything with that (though I didn't verify). Also, I don't really want to issue basically empty releases just for pre-commit (even though technically feasible), so the only option I can see is indeed the status quo.

Great, thanks for chatting about it.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  use a hook to synchronize the versions of `black` 1404894283
1275094649 https://github.com/pydata/xarray/pull/7153#issuecomment-1275094649 https://api.github.com/repos/pydata/xarray/issues/7153 IC_kwDOAMm_X85MAGZ5 max-sixty 5635139 2022-10-11T18:17:21Z 2022-10-11T18:17:21Z MEMBER

Unless you meant that black should be installed together with blackdoc? If that was the question: it already is, but will only be updated together with blackdoc, so now that I think of it that might actually make pinning in blackdoc redundant?

Without pinning black in additional_dependencies, which version is used? I think the issue might be that the latest version is used based on when it's installed. But that means that different people will have different versions. And so if we pin it within blackdoc, then people can't upgrade black without a new release of blackdoc. And so we're in this spot where each user needs to pin it within their .pre-commit-config.yaml.

Does pre-commit support additional_dependencies defined by the hook? I couldn't find it in https://pre-commit.com/#creating-new-hooks. That would solve this.

Otherwise I guess you could have a bot which released a new version of blackdoc pinned to each specific version of black. But the status quo seems OK too.

Ref https://github.com/pre-commit/pre-commit/issues/2082

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  use a hook to synchronize the versions of `black` 1404894283
1275074881 https://github.com/pydata/xarray/pull/7153#issuecomment-1275074881 https://api.github.com/repos/pydata/xarray/issues/7153 IC_kwDOAMm_X85MABlB keewis 14808389 2022-10-11T18:00:30Z 2022-10-11T18:00:59Z MEMBER

no, it's just that I don't think blackdoc will have a release cycle that's anything close to black's (every two months, judging by the last two releases), so unless a black release breaks blackdoc (which I hope it won't / have a CI to guard against), I think it's better to keep pinning in the user's configuration.

Unless you meant that black should be installed together with blackdoc? If that was the question: it already is, but will only be updated together with blackdoc, so now that I think of it that might actually make pinning in blackdoc redundant?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  use a hook to synchronize the versions of `black` 1404894283
1275059210 https://github.com/pydata/xarray/pull/7153#issuecomment-1275059210 https://api.github.com/repos/pydata/xarray/issues/7153 IC_kwDOAMm_X85L_9wK max-sixty 5635139 2022-10-11T17:47:02Z 2022-10-11T17:47:02Z MEMBER

As a great fan of blackdoc, can I ask a general question re blackdoc & pre-commit? Why not have the black dependency defined in the blackdoc requirements, so it gets installed without requiring additional-dependencies?

Is ti something to do with allowing people to use an old version of black with a new version of blackdoc, such that we don't want to have too aggressive a requirement?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  use a hook to synchronize the versions of `black` 1404894283

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);
Powered by Datasette · Queries took 22.694ms · About: xarray-datasette
  • Sort ascending
  • Sort descending
  • Facet by this
  • Hide this column
  • Show all columns
  • Show not-blank rows