From f30f9269b9d06d99c53ee147d18fc3149d7d6308 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 29 Dec 2022 11:39:37 -0700
Subject: [PATCH 01/14] Add: zenodo file to repo for citation

---
 .zenodo.json | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 .zenodo.json

diff --git a/.zenodo.json b/.zenodo.json
new file mode 100644
index 00000000..e8fd7bc4
--- /dev/null
+++ b/.zenodo.json
@@ -0,0 +1,48 @@
+{
+    "creators": [
+      {
+        "affiliation": "pyOpenSci",
+        "name": "Wasser, Leah",
+        "orcid": "0000-0002-8177-6550"
+      },
+      {
+        "affiliation": "",
+        "name": "Nicholson, David",
+        "orcid": "0000-0002-4261-4719"
+      },
+      {
+        "affiliation": "Hasso Plattner Institute",
+        "name": "Sasso, Ariane",
+        "orcid": "0000-0002-3669-4599"
+      },
+      {
+        "affiliation": "",
+        "name": "Batisse, Alexandre",
+        "orcid": "0000-0001-7912-3422"
+      }
+      {
+        "affiliation": "",
+        "name": "Molinsky, Simon",
+        "orcid": ""
+      },
+    ],
+    "contributors": [
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Marmo, Chiara",
+          "orcid": ""
+        },
+      ],
+    "keywords": [
+      "open source software",
+      "Python",
+      "open peer review",
+      "data science",
+      "open reproducible science",
+      "science"
+    ],
+    "license": "CC-BY-SA-4.0",
+    "upload_type": "publication",
+    "publication_type": "book"
+  }
\ No newline at end of file

From f1df23f77ae349650583cb80b6c8e6287aef425e Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 23 Mar 2023 11:10:15 -0600
Subject: [PATCH 02/14] Update .zenodo.json

Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
---
 .zenodo.json | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/.zenodo.json b/.zenodo.json
index e8fd7bc4..1a6849a2 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -33,6 +33,12 @@
           "name": "Marmo, Chiara",
           "orcid": ""
         },
+        {
+          "type":"Other",
+          "affiliation": "Quansight",
+          "name": "Pamphile T., Roy",
+          "orcid": "0000-0001-9816-1416"
+        },
       ],
     "keywords": [
       "open source software",

From 6e3bd48b892329a1634da53b4557ee0f41b14b4f Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 23 Mar 2023 11:10:21 -0600
Subject: [PATCH 03/14] Update .zenodo.json

Co-authored-by: Chiara Marmo <cmarmo@users.noreply.github.com>
---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index 1a6849a2..f66a6135 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -31,7 +31,7 @@
           "type":"Other",
           "affiliation": "",
           "name": "Marmo, Chiara",
-          "orcid": ""
+          "orcid": "0000-0003-2843-6044 "
         },
         {
           "type":"Other",

From a27e70515094b36dab73888d92ea9fdf4df1e688 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 23 Mar 2023 11:21:48 -0600
Subject: [PATCH 04/14] Update zenodo file with all contribs

---
 .zenodo.json                                |  84 ++++++
 package-structure-code/notes-from-review.md | 313 ++++++++++++++++++++
 2 files changed, 397 insertions(+)
 create mode 100644 package-structure-code/notes-from-review.md

diff --git a/.zenodo.json b/.zenodo.json
index f66a6135..9286a433 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -39,6 +39,90 @@
           "name": "Pamphile T., Roy",
           "orcid": "0000-0001-9816-1416"
         },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Welch, Erik",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Fernandes, Filipe",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Saunders, Jonny",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Döring, Randy",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Cano Rodríguez, Juan Luis",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Schreiner, Henry",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Van der Walt, Stéfan",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Schwartz, Eli",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Gommers, Ralf",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Gedam, Pradyun",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Lef, Ofek",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Tocknell, James",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "Ming, Frost",
+          "orcid": ""
+        },
+        {
+          "type":"Other",
+          "affiliation": "",
+          "name": "van Kemenade, Hugo",
+          "orcid": ""
+        },
       ],
     "keywords": [
       "open source software",
diff --git a/package-structure-code/notes-from-review.md b/package-structure-code/notes-from-review.md
new file mode 100644
index 00000000..ee11b849
--- /dev/null
+++ b/package-structure-code/notes-from-review.md
@@ -0,0 +1,313 @@
+<!-- ### Build tools for Python packages with complex build steps
+If your package is not pure Python, or it has complex build steps (or build
+steps that you need to customize), then you should consider using:
+
+* Setuptools
+* Hatch
+* PDM
+
+These tools allow you to customize your workflow with build steps needed
+to compile code. -->
+
+<!-- From stefan: build, run tests on built version, load the built version into
+Python (?how is this different from install??), make editable install, build
+wheel, build sdist -->
+
+<!--
+The example below is taken from [this thread in GitHub](https://github.com/py-pkgs/py-pkgs/issues/95#issuecomment-1035584750).
+
+```toml
+[tool.poetry.dependencies]
+python = ">=3.6" # This is muddled in as a dependency, while it's not like the others
+numpy = ">=1.13.3"
+typing_extensions = { version = ">=3.7", python = "<3.8" }
+
+sphinx = {version = "^4.0", optional = true}
+sphinx_book_theme = { version = ">=0.0.40", optional = true }
+sphinx_copybutton = { version = ">=0.3.1", optional = true }
+pytest = { version = ">=6", optional = true }
+importlib_metadata = { version = ">=1.0", optional = true, python = "<3.8" } # TOML error to add an ending comma or new line, even if this gets long
+boost-histogram = { version = ">=1.0", optional = true }
+
+[tool.poetry.dev-dependencies]
+pytest = ">=5.2"  # All the optional stuff above doesn't help here!
+importlib_metadata = {version = ">=1.0", python = "<3.8" }
+boost_histogram = ">=1.0"
+
+[tool.poetry.extras]
+docs = ["sphinx", "sphinx_book_theme", "sphinx_copybutton"]
+test = ["pytest", "importlib_metadata", "boost_histogram" ]
+```
+
+vs PDM
+
+```toml
+[project]
+requires-python = ">=3.6"
+dependencies = [
+  "numpy>=1.13.3",
+  "typing-extensions>=3.7; python_version<'3.8'",
+]
+
+# Only needed for extras
+[project.optional-dependencies]
+docs = [
+  "sphinx>=4.0",
+  "sphinx-book-theme>=0.0.40",
+  "sphinx-copybutton>=0.3.1",
+]
+test = [
+  "pytest>=6",
+  "importlib-metadata>=1.0; python_version<'3.8'",
+  "boost-histogram>=1.0",
+]
+
+# Only needed for "dev" installs
+[tool.pdm.dev-dependencies]
+dev = [
+  "pytest>=6",
+  "importlib-metadata>=1.0; python_version<'3.8'",
+  "boost-histogram>=1.0",
+]
+```
+
+From Eli:
+
+poetry: supports it (c extensions), but is undocumented and uses setuptools under the hood, they plan to change how this works and then document it
+pdm-back-end: supports it, and documents it -- and also uses setuptools under the hood
+hatchling: permits you to define hooks for you to write your own custom build steps, including to build C++ extensions
+
+
+**PDM** does have some support for `C`/[`Cython`](https://cython.org/) extensions. [Click here to
+learn more.](https://pdm.fming.dev/latest/pyproject/build/#build-platform-specific-wheels). This functionality uses setuptools "under the
+hood".
+
+
+-->
+
+<!--
+### Build front-ends
+
+Build front-ends have a user-friendly interface that allow you to perform
+common Python packaging tasks such as building your package, creating an
+environment to run package tests and build documentation, and pushing to PyPI.
+
+For instance, you can use **Flit**, **Hatch**, **Poetry** and **PDM** to both build your
+package and to publish your package to PyPI (or test PyPI). However, if you
+want a tool that also support environment management and versioning your package,
+then you might prefer to use **Hatch**, **Poetry** or **PDM**.
+
+Using a tool like **Flit**, **Hatch**, **Poetry** or **PDM** will simplify your workflow.
+
+Example to build your package with **Flit**:
+
+`flit build`
+
+Example to publish to PyPI:
+`flit publish --repository testpypi`
+
+In the Python package build space **setuptools** is
+the "OG" -the original tool that everyone used to use.
+With a tool like  `setuptools` you have the flexibility
+to publish python pure python packages and packages with custom build steps. However, you will also need to use other tools. For example, you will use `twine` to publish to PyPI.
+
+## An ecosystem of Python build tools
+
+Below we introduce several of the most commonly used
+Python packaging build  tools. Each tool has various
+features that might make you chose to use it
+or not use it. There is no right or wrong tool to use
+as far as pyOpenSci is concerned. We are just trying to
+help you find the tool that works best for
+your workflow.
+Example build steps using setuptools:
+======= -->
+
+<!-- TODO: create build tool selection diagram - https://www.canva.com/design/DAFawXrierc/O7DTnqW5fmMEZ31ao-TK9w/edit -->
+
+<!--
+On this page, we will focus on using front-end tools to package pure python
+packages. We will note if a package does have the flexibility to support other
+back-ends and in turn more complex builds (*mentioned in #2 and #3 above*). -->
+<!--
+## COmbine the two sets of statement below...
+ELI:
+PDM supports C/Cython extensions too: https://pdm.fming.dev/latest/pyproject/build/#build-platform-specific-wheels
+
+It does this by allowing you to write a python script that gets injected into a setuptools build process :) so that's not necessarily the greatest choice. It's a bit like using setuptools directly. ;)
+
+Ralf:
+Hatch only supports pure Python packages as of now. setuptools is still a very reasonable choice, and okay if all you have is a few C/Cython extensions. But I'd say you should probably recommend meson-python and scikit-build-core as the two best tools for building packages containing compiled extensions.
+
+
+* link to ralf's blog and book on complex builds
+* keep this page high level so we don't get weight downsides
+* can use the examplePy repo stefan and I are working on that will test various build combinations
+
+*****
+
+ELI: It would be more accurate to say that PDM supports using PDM and setuptools at the same time, so you run setuptools to produce the C extensions and then PDM receives the compiled extension files (.so, .pyd) and packages it up alongside the pure python files.
+
+Hatch - https://hatch.pypa.io/latest/config/build/#build-hooks uild hooks
+
+Ralf -
+Hatch has the worst take on building compiled code by some distance. Unless its author starts developing an understanding of build systems / needs, and implements support for PEP 517 build back-end hooks in pyproject.toml, it's pretty much a dead end.
+****
+
+
+ HEnry: Poetry will move to PEP 621 configuration in version 2.
+
+* pdm, hatch and poetry all have "ways" of supporting c extensions via pdm-backend, hatchling and poetry's build back-end.
+* poetry's support for C extensions is not fully developed and documented (yet). * Poetry doesn't offer a way to facilitate "communication" between poetry front end and another back-end like meson to build via a build hook. so while some have used it with other back-end builds it's not ideal for this application
+* pdm and poetry both rely on setuptools for C extensions. pdm's support claims to be fully developed and documented. poetry claims nothing, and doesn't document it.
+* hatch both offers a plugin type approach to support custom build steps
+PDM (right now) is the only tool that supports other back-ends (hatch is working on this - 2 minor releases away)
+At some point a build becomes so complex that you need to use a tool like scikit or meson to support that complexity.
+
+
+
+**Setuptools** is the oldest tool in the above list. While it doesn't have a
+friendly user front end, because "OG" tool that has been used for Python packaging for over a decade, we discuss it here.
+
+**Hatch** and PDM are newer, more modern tool that support customization of any
+part of your packaging steps. These tools also support some C and C++
+extensions.
+
+
+OFEK - Why use hatchlin vs pdm back-end -
+File inclusion is more configurable and easier by default
+There is already a rich ecosystem of plugins and a well-thought-out interface
+Consistency since the official Python packaging tutorial uses Hatchling by default
+
+
+Henry -
+The scikit-hep cookie provides 11 back-ends including flit-core and hatchling, and I've moved packaging to flit-core, and lots of other things to hatchling, and I can say that hatching's defaults are much nicer than flit-core's. Hatching uses .gitignore to decide what to put in the sdist. Flit-core basically tries to keep its hands off of adding defaults, so you have to configure everything manually. To make it even more confusing, if you use flit instead of a standard tool like build, it will switch to using VCS and those ignored files won't be added - meaning it is really easy to have a project that doesn't support build, including various GitHub Actions. Hatchling wins this by a ton.
+
+<!-- TODO: add - compatible with other build back-ends eg pdm can work with hatchling
+
+Eli:
+poetry: supports it, but is undocumented and uses setuptools under the hood, they plan to change how this works and then document it
+pdm-back-end: supports it, and documents it -- and also uses setuptools under the hood
+hatchling: permits you to define hooks for you to write your own custom build steps, including to build C++ extensions
+
+-->
+
+<!-- from eli about pdm
+It would be more accurate to say that PDM supports using PDM and setuptools at the same time, so you run setuptools to produce the C extensions and then PDM receives the compiled extension files (.so, .pyd) and packages it up alongside the pure Python files.
+
+Comment about hatch.
+https://github.com/pyOpenSci/python-package-guide/pull/23#discussion_r1081108118
+
+From ralf: There are no silver bullets here yet, no workflow tool is complete. Both Hatch and PDM are single-author tools, which is another concern. @eli-schwartz's assessment is unfortunately correct here I believe (at a high level at least, not sure about details). Hatch has the worst take on building compiled code by some distance. Unless its author starts developing an understanding of build systems / needs, and implements support for PEP 517 build back-end hooks in pyproject.toml, it's pretty much a dead end.
+
+-->
+
+<!--TODO Add examples of builds using each of the tools below?
+
+pdm, hatch and poetry all have "ways" of supporting c extensions via pdm-build, hatchling and poetry's build back-end.
+poetry's support for C extensions is not fully developed and documented (yet). Poetry doesn't offer a way to facilitate "communication" between poetry front end and another back-end like meson to build via a build hook.
+PDM and hatch both offer a plugin type approach to support custom build steps
+PDM (right now) is the only tool that supports other back-ends (hatch is working on this - 2 minor releases away)
+At some point a build becomes so complex that you need to use a tool like scikit or meson to support that complexity.
+
+CORRECTIONS:
+pdm doesn't use plugins. Hatch does.
+pdm and poetry both rely on setuptools for C extensions. pdm's support claims to be fully developed and documented. poetry claims nothing, and doesn't document it.
+
+
+??
+Poetry supports extensions written in other languages but this functionality is
+currently undocumented.
+
+Tools such as Setuptools, PDM, Hatch and Poetry all have some level of support
+for C and C++ extensions.
+Some Python packaging tools,
+such as **Flit** and the **flit-core** build back-end only support pure-Python
+package builds.
+Some front-end packaging tools, such as PDM, allow you to use other
+build back-ends such as **meson** and **scikit-build**.
+
+
+me:
+pdm, hatch and poetry all have "ways" of supporting c extensions via pdm-build, hatchling and poetry's build back-end.
+poetry's support for C extensions is not fully developed and documented (yet). Poetry doesn't offer a way to facilitate "communication" between poetry front end and another back-end like meson to build via a build hook.
+PDM and hatch both offer a plugin type approach to support custom build steps
+PDM (right now) is the only tool that supports other back-ends (hatch is working on this - 2 minor releases away)
+At some point a build becomes so complex that you need to use a tool like scikit or meson to support that complexity.
+@eli-schwartz eli-schwartz 3 weeks ago
+PDM and hatch both offer a plugin type approach to support custom build steps
+
+ELI:
+pdm doesn't use plugins. Hatch does.
+pdm and poetry both rely on setuptools for C extensions. pdm's support claims to be fully developed and documented. poetry claims nothing, and doesn't document it.
+
+
+https://pdm.fming.dev/latest/pyproject/build/#build-platform-specific-wheels
+-->
+
+<!-- https://github.com/pyOpenSci/python-package-guide/pull/23#discussion_r1071541329
+ELI: A complex build could mean running a python script that processes some data file and produces a pure python module file.
+
+Probably not common in the scientific community specifically, but I've seen quite a few setup.py files that contain custom build stages which e.g. build gettext locale catalogs.
+
+The main point is that it is more "complex" than simply copying files or directories as-is into the built wheel.
+-->
+
+<!--
+COMMENTED OUT TEXT TO BE MOVED
+
+
+# TODO LINK TO CI BUILDS FOR Documentation>
+Maybe we can curate a list of CI builds that people can use??? or is that moving too close to a cookie cutter situation
+
+The text below is being moved to the packaging infrastructure section which
+doesn't exist YET... but will soon .
+pyOpenSci packages must:
+
+- Contain full documentation for any user-facing functions.
+- Have a test suite that covers the major functionality of the package.
+- Use continuous integration.
+- Use an OSI approved software license.
+
+
+## Other recommendations
+### Python version support
+You should always be explicit about which versions of Python your package supports.
+Keeping compatibility with old Python versions can be difficult as functionality changes.
+A good rule of thumb is that the package should support, at least,
+the latest three Python versions (e.g., 3.8, 3.7, 3.6).
+
+### Code Style
+pyOpenSci encourages authors to consult [PEP 8](https://www.python.org/dev/peps/pep-0008/) for information on how to style your code.
+
+### Linting
+An automatic linter (e.g. flake8) can help ensure your code is clean and free of syntax errors. These can be integrated with your CI.
+
+-->
+
+<!--
+```{tip}
+### Python packaging resources that we love
+
+We think the resources below are excellent but each have particular opinions
+that you may or may not find in our packaging guide. For instance, the PyPA
+guide encourages users to store their package in a `src/package-name` directory.
+While we accept that approach many of our community members prefer to not use
+the `src` directory.
+
+* [Python packaging for research software engineers](https://merely-useful.tech/py-rse/)
+* [PyPA packaging guide](https://packaging.python.org/en/latest/)
+```
+-->
+
+<!--
+* one of the benefits of wheel is pretty much avoiding setup.py which
+has code mixed in. makes you more vulnerable to a code injection on install.
+
+assuming this means if the package is already pre-built than setup.py isn't running anything on install because install is just moving files across to the machine to be run.
+
+And having metadata separate allows someone to view the metadata without
+running any python code as it's a machine and human readable format.
+
+https://scikit-hep.org/developer/pep621
+-->

From de300d0b7d0ee7628b997e7cca2d1269709f07d5 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Mon, 27 Mar 2023 15:55:58 -0600
Subject: [PATCH 05/14] Update .zenodo.json

Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
---
 .zenodo.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.zenodo.json b/.zenodo.json
index 9286a433..1f7a3e73 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -71,9 +71,9 @@
         },
         {
           "type":"Other",
-          "affiliation": "",
+          "affiliation": "Princeton University",
           "name": "Schreiner, Henry",
-          "orcid": ""
+          "orcid": "0000-0002-7833-783X"
         },
         {
           "type":"Other",

From 3e6418e234e57e57da371f46250a785f88d049a9 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Mon, 27 Mar 2023 15:56:15 -0600
Subject: [PATCH 06/14] Update .zenodo.json

Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index 1f7a3e73..4a77a33e 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -121,7 +121,7 @@
           "type":"Other",
           "affiliation": "",
           "name": "van Kemenade, Hugo",
-          "orcid": ""
+          "orcid": "0000-0001-5715-8632"
         },
       ],
     "keywords": [

From 40a3bad1059d13b66552853efa4c3e931eda6891 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Mon, 27 Mar 2023 15:56:21 -0600
Subject: [PATCH 07/14] Update .zenodo.json
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Juan Luis Cano Rodríguez <hello@juanlu.space>
---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index 4a77a33e..406aa0f3 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -67,7 +67,7 @@
           "type":"Other",
           "affiliation": "",
           "name": "Cano Rodríguez, Juan Luis",
-          "orcid": ""
+          "orcid": "0000-0002-2187-161X"
         },
         {
           "type":"Other",

From b1e05b50f5e707f23d54b85170655cf91ff94802 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Mon, 27 Mar 2023 15:57:27 -0600
Subject: [PATCH 08/14] Apply suggestions from code review

---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index 406aa0f3..f4ecb071 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -91,7 +91,7 @@
           "type":"Other",
           "affiliation": "",
           "name": "Gommers, Ralf",
-          "orcid": ""
+          "orcid": "0000-0002-0300-3333"
         },
         {
           "type":"Other",

From 83852671abea3cc0ddda02eaa7372b08c5e635b1 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Mon, 27 Mar 2023 15:57:36 -0600
Subject: [PATCH 09/14] Update .zenodo.json

---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index f4ecb071..a1bcc09f 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -89,7 +89,7 @@
         },
         {
           "type":"Other",
-          "affiliation": "",
+          "affiliation": "Quansight",
           "name": "Gommers, Ralf",
           "orcid": "0000-0002-0300-3333"
         },

From e5506af83f4b28ba7bc0c8b679288102bbde1455 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 27 Mar 2023 22:05:57 +0000
Subject: [PATCH 10/14] =?UTF-8?q?'[pre-commit.ci=20=F0=9F=A4=96]=20Apply?=
 =?UTF-8?q?=20code=20format=20tools=20to=20PR'?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index a1bcc09f..ec780643 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -135,4 +135,4 @@
     "license": "CC-BY-SA-4.0",
     "upload_type": "publication",
     "publication_type": "book"
-  }
\ No newline at end of file
+  }

From ac0ff4c8404f53f8c21aafe0d6bf53834c3f1780 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 30 Mar 2023 12:41:34 -0600
Subject: [PATCH 11/14] Update .zenodo.json

Co-authored-by: Erik Welch <erik.n.welch@gmail.com>
---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index ec780643..c626ad19 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -41,7 +41,7 @@
         },
         {
           "type":"Other",
-          "affiliation": "",
+          "affiliation": "NVIDIA",
           "name": "Welch, Erik",
           "orcid": ""
         },

From 2dc0c85fbddbf101a7ddc97fde64e2ef2667dc87 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 30 Mar 2023 12:41:39 -0600
Subject: [PATCH 12/14] Update .zenodo.json

Co-authored-by: Erik Welch <erik.n.welch@gmail.com>
---
 .zenodo.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.zenodo.json b/.zenodo.json
index c626ad19..bb11c982 100644
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -43,7 +43,7 @@
           "type":"Other",
           "affiliation": "NVIDIA",
           "name": "Welch, Erik",
-          "orcid": ""
+          "orcid": "0000-0003-3694-3783"
         },
         {
           "type":"Other",

From ee8f206bc2cbf34b795f2c6291810f13aaa75717 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 30 Mar 2023 12:42:48 -0600
Subject: [PATCH 13/14] Update notes-from-review.md

---
 package-structure-code/notes-from-review.md | 312 --------------------
 1 file changed, 312 deletions(-)

diff --git a/package-structure-code/notes-from-review.md b/package-structure-code/notes-from-review.md
index ee11b849..8b137891 100644
--- a/package-structure-code/notes-from-review.md
+++ b/package-structure-code/notes-from-review.md
@@ -1,313 +1 @@
-<!-- ### Build tools for Python packages with complex build steps
-If your package is not pure Python, or it has complex build steps (or build
-steps that you need to customize), then you should consider using:
 
-* Setuptools
-* Hatch
-* PDM
-
-These tools allow you to customize your workflow with build steps needed
-to compile code. -->
-
-<!-- From stefan: build, run tests on built version, load the built version into
-Python (?how is this different from install??), make editable install, build
-wheel, build sdist -->
-
-<!--
-The example below is taken from [this thread in GitHub](https://github.com/py-pkgs/py-pkgs/issues/95#issuecomment-1035584750).
-
-```toml
-[tool.poetry.dependencies]
-python = ">=3.6" # This is muddled in as a dependency, while it's not like the others
-numpy = ">=1.13.3"
-typing_extensions = { version = ">=3.7", python = "<3.8" }
-
-sphinx = {version = "^4.0", optional = true}
-sphinx_book_theme = { version = ">=0.0.40", optional = true }
-sphinx_copybutton = { version = ">=0.3.1", optional = true }
-pytest = { version = ">=6", optional = true }
-importlib_metadata = { version = ">=1.0", optional = true, python = "<3.8" } # TOML error to add an ending comma or new line, even if this gets long
-boost-histogram = { version = ">=1.0", optional = true }
-
-[tool.poetry.dev-dependencies]
-pytest = ">=5.2"  # All the optional stuff above doesn't help here!
-importlib_metadata = {version = ">=1.0", python = "<3.8" }
-boost_histogram = ">=1.0"
-
-[tool.poetry.extras]
-docs = ["sphinx", "sphinx_book_theme", "sphinx_copybutton"]
-test = ["pytest", "importlib_metadata", "boost_histogram" ]
-```
-
-vs PDM
-
-```toml
-[project]
-requires-python = ">=3.6"
-dependencies = [
-  "numpy>=1.13.3",
-  "typing-extensions>=3.7; python_version<'3.8'",
-]
-
-# Only needed for extras
-[project.optional-dependencies]
-docs = [
-  "sphinx>=4.0",
-  "sphinx-book-theme>=0.0.40",
-  "sphinx-copybutton>=0.3.1",
-]
-test = [
-  "pytest>=6",
-  "importlib-metadata>=1.0; python_version<'3.8'",
-  "boost-histogram>=1.0",
-]
-
-# Only needed for "dev" installs
-[tool.pdm.dev-dependencies]
-dev = [
-  "pytest>=6",
-  "importlib-metadata>=1.0; python_version<'3.8'",
-  "boost-histogram>=1.0",
-]
-```
-
-From Eli:
-
-poetry: supports it (c extensions), but is undocumented and uses setuptools under the hood, they plan to change how this works and then document it
-pdm-back-end: supports it, and documents it -- and also uses setuptools under the hood
-hatchling: permits you to define hooks for you to write your own custom build steps, including to build C++ extensions
-
-
-**PDM** does have some support for `C`/[`Cython`](https://cython.org/) extensions. [Click here to
-learn more.](https://pdm.fming.dev/latest/pyproject/build/#build-platform-specific-wheels). This functionality uses setuptools "under the
-hood".
-
-
--->
-
-<!--
-### Build front-ends
-
-Build front-ends have a user-friendly interface that allow you to perform
-common Python packaging tasks such as building your package, creating an
-environment to run package tests and build documentation, and pushing to PyPI.
-
-For instance, you can use **Flit**, **Hatch**, **Poetry** and **PDM** to both build your
-package and to publish your package to PyPI (or test PyPI). However, if you
-want a tool that also support environment management and versioning your package,
-then you might prefer to use **Hatch**, **Poetry** or **PDM**.
-
-Using a tool like **Flit**, **Hatch**, **Poetry** or **PDM** will simplify your workflow.
-
-Example to build your package with **Flit**:
-
-`flit build`
-
-Example to publish to PyPI:
-`flit publish --repository testpypi`
-
-In the Python package build space **setuptools** is
-the "OG" -the original tool that everyone used to use.
-With a tool like  `setuptools` you have the flexibility
-to publish python pure python packages and packages with custom build steps. However, you will also need to use other tools. For example, you will use `twine` to publish to PyPI.
-
-## An ecosystem of Python build tools
-
-Below we introduce several of the most commonly used
-Python packaging build  tools. Each tool has various
-features that might make you chose to use it
-or not use it. There is no right or wrong tool to use
-as far as pyOpenSci is concerned. We are just trying to
-help you find the tool that works best for
-your workflow.
-Example build steps using setuptools:
-======= -->
-
-<!-- TODO: create build tool selection diagram - https://www.canva.com/design/DAFawXrierc/O7DTnqW5fmMEZ31ao-TK9w/edit -->
-
-<!--
-On this page, we will focus on using front-end tools to package pure python
-packages. We will note if a package does have the flexibility to support other
-back-ends and in turn more complex builds (*mentioned in #2 and #3 above*). -->
-<!--
-## COmbine the two sets of statement below...
-ELI:
-PDM supports C/Cython extensions too: https://pdm.fming.dev/latest/pyproject/build/#build-platform-specific-wheels
-
-It does this by allowing you to write a python script that gets injected into a setuptools build process :) so that's not necessarily the greatest choice. It's a bit like using setuptools directly. ;)
-
-Ralf:
-Hatch only supports pure Python packages as of now. setuptools is still a very reasonable choice, and okay if all you have is a few C/Cython extensions. But I'd say you should probably recommend meson-python and scikit-build-core as the two best tools for building packages containing compiled extensions.
-
-
-* link to ralf's blog and book on complex builds
-* keep this page high level so we don't get weight downsides
-* can use the examplePy repo stefan and I are working on that will test various build combinations
-
-*****
-
-ELI: It would be more accurate to say that PDM supports using PDM and setuptools at the same time, so you run setuptools to produce the C extensions and then PDM receives the compiled extension files (.so, .pyd) and packages it up alongside the pure python files.
-
-Hatch - https://hatch.pypa.io/latest/config/build/#build-hooks uild hooks
-
-Ralf -
-Hatch has the worst take on building compiled code by some distance. Unless its author starts developing an understanding of build systems / needs, and implements support for PEP 517 build back-end hooks in pyproject.toml, it's pretty much a dead end.
-****
-
-
- HEnry: Poetry will move to PEP 621 configuration in version 2.
-
-* pdm, hatch and poetry all have "ways" of supporting c extensions via pdm-backend, hatchling and poetry's build back-end.
-* poetry's support for C extensions is not fully developed and documented (yet). * Poetry doesn't offer a way to facilitate "communication" between poetry front end and another back-end like meson to build via a build hook. so while some have used it with other back-end builds it's not ideal for this application
-* pdm and poetry both rely on setuptools for C extensions. pdm's support claims to be fully developed and documented. poetry claims nothing, and doesn't document it.
-* hatch both offers a plugin type approach to support custom build steps
-PDM (right now) is the only tool that supports other back-ends (hatch is working on this - 2 minor releases away)
-At some point a build becomes so complex that you need to use a tool like scikit or meson to support that complexity.
-
-
-
-**Setuptools** is the oldest tool in the above list. While it doesn't have a
-friendly user front end, because "OG" tool that has been used for Python packaging for over a decade, we discuss it here.
-
-**Hatch** and PDM are newer, more modern tool that support customization of any
-part of your packaging steps. These tools also support some C and C++
-extensions.
-
-
-OFEK - Why use hatchlin vs pdm back-end -
-File inclusion is more configurable and easier by default
-There is already a rich ecosystem of plugins and a well-thought-out interface
-Consistency since the official Python packaging tutorial uses Hatchling by default
-
-
-Henry -
-The scikit-hep cookie provides 11 back-ends including flit-core and hatchling, and I've moved packaging to flit-core, and lots of other things to hatchling, and I can say that hatching's defaults are much nicer than flit-core's. Hatching uses .gitignore to decide what to put in the sdist. Flit-core basically tries to keep its hands off of adding defaults, so you have to configure everything manually. To make it even more confusing, if you use flit instead of a standard tool like build, it will switch to using VCS and those ignored files won't be added - meaning it is really easy to have a project that doesn't support build, including various GitHub Actions. Hatchling wins this by a ton.
-
-<!-- TODO: add - compatible with other build back-ends eg pdm can work with hatchling
-
-Eli:
-poetry: supports it, but is undocumented and uses setuptools under the hood, they plan to change how this works and then document it
-pdm-back-end: supports it, and documents it -- and also uses setuptools under the hood
-hatchling: permits you to define hooks for you to write your own custom build steps, including to build C++ extensions
-
--->
-
-<!-- from eli about pdm
-It would be more accurate to say that PDM supports using PDM and setuptools at the same time, so you run setuptools to produce the C extensions and then PDM receives the compiled extension files (.so, .pyd) and packages it up alongside the pure Python files.
-
-Comment about hatch.
-https://github.com/pyOpenSci/python-package-guide/pull/23#discussion_r1081108118
-
-From ralf: There are no silver bullets here yet, no workflow tool is complete. Both Hatch and PDM are single-author tools, which is another concern. @eli-schwartz's assessment is unfortunately correct here I believe (at a high level at least, not sure about details). Hatch has the worst take on building compiled code by some distance. Unless its author starts developing an understanding of build systems / needs, and implements support for PEP 517 build back-end hooks in pyproject.toml, it's pretty much a dead end.
-
--->
-
-<!--TODO Add examples of builds using each of the tools below?
-
-pdm, hatch and poetry all have "ways" of supporting c extensions via pdm-build, hatchling and poetry's build back-end.
-poetry's support for C extensions is not fully developed and documented (yet). Poetry doesn't offer a way to facilitate "communication" between poetry front end and another back-end like meson to build via a build hook.
-PDM and hatch both offer a plugin type approach to support custom build steps
-PDM (right now) is the only tool that supports other back-ends (hatch is working on this - 2 minor releases away)
-At some point a build becomes so complex that you need to use a tool like scikit or meson to support that complexity.
-
-CORRECTIONS:
-pdm doesn't use plugins. Hatch does.
-pdm and poetry both rely on setuptools for C extensions. pdm's support claims to be fully developed and documented. poetry claims nothing, and doesn't document it.
-
-
-??
-Poetry supports extensions written in other languages but this functionality is
-currently undocumented.
-
-Tools such as Setuptools, PDM, Hatch and Poetry all have some level of support
-for C and C++ extensions.
-Some Python packaging tools,
-such as **Flit** and the **flit-core** build back-end only support pure-Python
-package builds.
-Some front-end packaging tools, such as PDM, allow you to use other
-build back-ends such as **meson** and **scikit-build**.
-
-
-me:
-pdm, hatch and poetry all have "ways" of supporting c extensions via pdm-build, hatchling and poetry's build back-end.
-poetry's support for C extensions is not fully developed and documented (yet). Poetry doesn't offer a way to facilitate "communication" between poetry front end and another back-end like meson to build via a build hook.
-PDM and hatch both offer a plugin type approach to support custom build steps
-PDM (right now) is the only tool that supports other back-ends (hatch is working on this - 2 minor releases away)
-At some point a build becomes so complex that you need to use a tool like scikit or meson to support that complexity.
-@eli-schwartz eli-schwartz 3 weeks ago
-PDM and hatch both offer a plugin type approach to support custom build steps
-
-ELI:
-pdm doesn't use plugins. Hatch does.
-pdm and poetry both rely on setuptools for C extensions. pdm's support claims to be fully developed and documented. poetry claims nothing, and doesn't document it.
-
-
-https://pdm.fming.dev/latest/pyproject/build/#build-platform-specific-wheels
--->
-
-<!-- https://github.com/pyOpenSci/python-package-guide/pull/23#discussion_r1071541329
-ELI: A complex build could mean running a python script that processes some data file and produces a pure python module file.
-
-Probably not common in the scientific community specifically, but I've seen quite a few setup.py files that contain custom build stages which e.g. build gettext locale catalogs.
-
-The main point is that it is more "complex" than simply copying files or directories as-is into the built wheel.
--->
-
-<!--
-COMMENTED OUT TEXT TO BE MOVED
-
-
-# TODO LINK TO CI BUILDS FOR Documentation>
-Maybe we can curate a list of CI builds that people can use??? or is that moving too close to a cookie cutter situation
-
-The text below is being moved to the packaging infrastructure section which
-doesn't exist YET... but will soon .
-pyOpenSci packages must:
-
-- Contain full documentation for any user-facing functions.
-- Have a test suite that covers the major functionality of the package.
-- Use continuous integration.
-- Use an OSI approved software license.
-
-
-## Other recommendations
-### Python version support
-You should always be explicit about which versions of Python your package supports.
-Keeping compatibility with old Python versions can be difficult as functionality changes.
-A good rule of thumb is that the package should support, at least,
-the latest three Python versions (e.g., 3.8, 3.7, 3.6).
-
-### Code Style
-pyOpenSci encourages authors to consult [PEP 8](https://www.python.org/dev/peps/pep-0008/) for information on how to style your code.
-
-### Linting
-An automatic linter (e.g. flake8) can help ensure your code is clean and free of syntax errors. These can be integrated with your CI.
-
--->
-
-<!--
-```{tip}
-### Python packaging resources that we love
-
-We think the resources below are excellent but each have particular opinions
-that you may or may not find in our packaging guide. For instance, the PyPA
-guide encourages users to store their package in a `src/package-name` directory.
-While we accept that approach many of our community members prefer to not use
-the `src` directory.
-
-* [Python packaging for research software engineers](https://merely-useful.tech/py-rse/)
-* [PyPA packaging guide](https://packaging.python.org/en/latest/)
-```
--->
-
-<!--
-* one of the benefits of wheel is pretty much avoiding setup.py which
-has code mixed in. makes you more vulnerable to a code injection on install.
-
-assuming this means if the package is already pre-built than setup.py isn't running anything on install because install is just moving files across to the machine to be run.
-
-And having metadata separate allows someone to view the metadata without
-running any python code as it's a machine and human readable format.
-
-https://scikit-hep.org/developer/pep621
--->

From fd4b284ef6f37546a0f65e39dc4e285a6f406a36 Mon Sep 17 00:00:00 2001
From: Leah Wasser <leah@pyopensci.org>
Date: Thu, 30 Mar 2023 12:43:01 -0600
Subject: [PATCH 14/14] remove notes

---
 package-structure-code/notes-from-review.md | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 package-structure-code/notes-from-review.md

diff --git a/package-structure-code/notes-from-review.md b/package-structure-code/notes-from-review.md
deleted file mode 100644
index 8b137891..00000000
--- a/package-structure-code/notes-from-review.md
+++ /dev/null
@@ -1 +0,0 @@
-