pull_requests
6 rows where user = 1828519
This data as json, CSV (advanced)
Suggested facets: state, created_at (date), updated_at (date), closed_at (date), merged_at (date)
| id ▼ | node_id | number | state | locked | title | user | body | created_at | updated_at | closed_at | merged_at | merge_commit_sha | assignee | milestone | draft | head | base | author_association | auto_merge | repo | url | merged_by |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 220706493 | MDExOlB1bGxSZXF1ZXN0MjIwNzA2NDkz | 2465 | closed | 0 | Add python_requires to setup.py | djhoese 1828519 | This should assist users using PyPI/pip to install xarray when xarray drops python 2.7 support. The `python_requires` argument is described here: https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires Basically, it says what versions of python your package supports. When xarray drops python 2 support and this kwarg gets update it should stop people on python 2 from getting the wrong package. - [x] Tests passed (for all non-documentation changes) | 2018-10-05T13:43:06Z | 2018-10-06T07:49:08Z | 2018-10-06T07:48:58Z | 2018-10-06T07:48:58Z | 4a7a103204989af7e2b6bc97a4109d81beebd34c | 0 | a771c911a07ff04058d3cc68fa47ab79176eeabd | 3cef8d730d5bbd699a393fa15266064ebb9849e2 | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/2465 | ||||
| 247899648 | MDExOlB1bGxSZXF1ZXN0MjQ3ODk5NjQ4 | 2715 | closed | 0 | Fix CRS being WKT instead of PROJ.4 | djhoese 1828519 | See https://github.com/mapbox/rasterio/blob/master/CHANGES.txt#L7 for the change in rasterio 1.0.14 and my conda-forge issue where I discovered this: https://github.com/conda-forge/gdal-feedstock/issues/262 This was put in a bugfix (micro version number) release of rasterio which made it harder to discover. @sgillies @snowman2 I saw that you brought this up and how it affected xarray (https://rasterio.groups.io/g/dev/message/68). If this pull request is a duplicate of a fix one of you made let me know. To xarray devs, if I need to make any other changes (whats-new?) also let me know. - [ ] Closes #xxxx - [ ] Tests added - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-01-26T16:46:11Z | 2019-03-12T18:57:44Z | 2019-02-06T16:56:07Z | 2019-02-06T16:56:06Z | 0c73a380745c4792ab440eb020f78f203897abe5 | 0 | 4e827b72cc8a0e2adbac650a2b65ce4953baff39 | e677b7a0aa344faee3eb407e63422038c2029399 | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/2715 | ||||
| 286515468 | MDExOlB1bGxSZXF1ZXN0Mjg2NTE1NDY4 | 3006 | closed | 0 | Fix 'to_masked_array' computing dask arrays twice | djhoese 1828519 | I ran in to this issue when using `imshow` on a dask-based `DataArray` and dask's `ProgressBar()` context manager. I noticed that when using `my_data_arr.plot.imshow` the dask array was being computed twice. This PR fixes that. Suggestions for tests and documenting this fix are welcome. - [ ] Closes #xxxx - [ ] Tests added - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-06-10T01:33:08Z | 2019-06-25T16:56:19Z | 2019-06-10T13:25:58Z | 2019-06-10T13:25:58Z | adbd59a0498cce298d88d9383837c968bebae538 | 0 | c7a81b98bc556569a15ce01aedbd8524ccc06c08 | 44011c9857b249b65b5f403d2791e198e3d67a87 | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/3006 | ||||
| 306491733 | MDExOlB1bGxSZXF1ZXN0MzA2NDkxNzMz | 3209 | closed | 0 | Add note about accessor instance creation | djhoese 1828519 | This is an attempt at clarifying accessor docs to help with the confusion I had in #3205. I'm not sure how many other xarray doc pages use `.. note::` but it seemed useable here. I'm not sure this is worth the explanation or if it is worded the best, but thought this could start the discussion. - [ ] Closes #3205 - [ ] Tests added - [ ] Passes `black . && mypy . && flake8` - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-08-12T13:17:13Z | 2019-08-14T13:08:54Z | 2019-08-14T05:33:49Z | 2019-08-14T05:33:48Z | 2fdcbb6feccb01a97b8b51160b81e238486fff00 | 0 | 14dca12191e7ab82a74599e5ae56fbd078a13f0c | b0df4d901ad7625b0ffabc8d85775efaca9d2c2f | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/3209 | ||||
| 1386907083 | PR_kwDOAMm_X85SqoXL | 7905 | open | 0 | Add '.hdf' extension to 'netcdf4' backend | djhoese 1828519 | I'm helping @joleenf debug an issue where some old code that uses `xr.open_dataset` no longer works since the introduction of engines or at least as far as we can tell. The main issue is that she's using code that assumes the NetCDF4 C library was compiled with HDF4 support (ex. conda-forge builds with this functionality enabled). So in this case `netCDF4.Dataset("my_file.hdf")` can actually read the HDF4 file through the NetCDF4 C library. However, with `xr.open_dataset("my_file.hdf")` will fail because xarray (or rather the netcdf4 engine) doesn't know that it could potentially read HDF4 files. This PR adds the `.hdf` extension to the 'netcdf4' engine to allow this to be automatic without needing `engine='netcdf4'` to be specified. What do people think? I didn't want to put any more work into this until others weighed in. - [ ] Closes #xxxx - [ ] Tests added - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [ ] New functions/methods are listed in `api.rst` | 2023-06-10T00:45:15Z | 2023-06-14T15:25:08Z | 3df1dc60eb0250a11655e15289454b06ba29f86d | 0 | 9abc5ba691bd4200cf1561d31cfd78d6434ce684 | 3459e6fa3c41b9e7b796800682bcf1408467cf1e | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/7905 | ||||||
| 1824051470 | PR_kwDOAMm_X85suNEO | 8946 | open | 0 | Fix upcasting with python builtin numbers and numpy 2 | djhoese 1828519 | See #8402 for more discussion. Bottom line is that numpy 2 changes the rules for casting between two inputs. Due to this and xarray's preference for promoting python scalars to 0d arrays (scalar arrays), xarray objects are being upcast to higher data types when they previously didn't. I'm mainly opening this PR for further and more detailed discussion. CC @dcherian - [ ] Closes #8402 - [ ] Tests added - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [ ] New functions/methods are listed in `api.rst` | 2024-04-15T20:07:42Z | 2024-04-29T12:38:55Z | 9db1a51b4d15279fb91d1f8802a1139ee5e76c18 | 0 | 5b4384fe279abc8eb0b8a4b18c2696e82c59285a | 9eb180b7b3df869c21518a17c6fa9eb456551d21 | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/8946 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [pull_requests] (
[id] INTEGER PRIMARY KEY,
[node_id] TEXT,
[number] INTEGER,
[state] TEXT,
[locked] INTEGER,
[title] TEXT,
[user] INTEGER REFERENCES [users]([id]),
[body] TEXT,
[created_at] TEXT,
[updated_at] TEXT,
[closed_at] TEXT,
[merged_at] TEXT,
[merge_commit_sha] TEXT,
[assignee] INTEGER REFERENCES [users]([id]),
[milestone] INTEGER REFERENCES [milestones]([id]),
[draft] INTEGER,
[head] TEXT,
[base] TEXT,
[author_association] TEXT,
[auto_merge] TEXT,
[repo] INTEGER REFERENCES [repos]([id]),
[url] TEXT,
[merged_by] INTEGER REFERENCES [users]([id])
);
CREATE INDEX [idx_pull_requests_merged_by]
ON [pull_requests] ([merged_by]);
CREATE INDEX [idx_pull_requests_repo]
ON [pull_requests] ([repo]);
CREATE INDEX [idx_pull_requests_milestone]
ON [pull_requests] ([milestone]);
CREATE INDEX [idx_pull_requests_assignee]
ON [pull_requests] ([assignee]);
CREATE INDEX [idx_pull_requests_user]
ON [pull_requests] ([user]);