Skip to content
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

hudpy: A Python interface for the US Department of Housing and Urban Development APIs #54

Closed
12 of 22 tasks
etam4260 opened this issue Jun 13, 2022 · 7 comments
Closed
12 of 22 tasks
Labels
0/pre-review-checks New Submission! on-hold A tag to represent packages on review hold until we figure out a bigger issue associate with review

Comments

@etam4260
Copy link

Submitting Author: @etam4260
Package Name: hudpy
One-Line Description of Package: A Python Interface to the US Department of Housing and Urban Development APIs
Repository Link: https://github.com/etam4260/hudpy
Version submitted: 0.2.0
Editor: TBD
Reviewer 1: TBD
Reviewer 2: TBD
Archive: TBD
Version accepted: TBD


Description

  • Include a brief paragraph describing what your package does:

Currently the R version is under peer review at ROpenSci:
ropensci/software-review#524

This package is a mapped over version from R to Python.

This package gives users access to the US Department of Housing and Urban Development APIs
available at HUD User:
https://www.huduser.gov/hudapi/public/login

This also has additional wrappers onto of the data provided from these APIs to determine if US geographies intersect
based on addresses and (cross walking a US dataset) explained in this paper below:

Wilson, Ron and Din, Alexander, 2018. “Understanding and Enhancing the U.S.
Department of Housing and Urban Development’s ZIP Code Crosswalk Files,”
Cityscape: A Journal of Policy Development and Research, Volume 20 Number 2, 277
https://www.huduser.gov/portal/periodicals/cityscpe/vol20num2/ch16.pdf

Scope

  • Please indicate which category or categories this package falls under:
    • Data retrieval
    • Data extraction
    • Data munging
    • Data deposition
    • Reproducibility
    • Geospatial
    • Education
    • Data visualization*

Please fill out a pre-submission inquiry before submitting a data visualization package. For more info, see notes on categories of our guidebook.

NA

  • For all submissions, explain how the and why the package falls under the categories you indicated above. In your explanation, please address the following points (briefly, 1-2 sentences for each):

It is a data retrieval package because it retrieves data from an API. It is data munging package because it implements the concept of cross walking a file (converting a dataset described in one US geographic identifier into another) explained in the paper mentioned above.

  • Who is the target audience and what are scientific applications of this package?

I am hoping to reach professors, researchers, and students with this package. This gives access to the crosswalk files which is a geospatial technique described very well in these journal articles:

Din, Alexander and Wilson, Ron, 2020. “Crosswalking ZIP Codes to Census Geographies: Geoprocessing the U.S. Department of Housing & Urban Development’s ZIP Code Crosswalk Files,” Cityscape: A Journal of Policy Development and Research, Volume 22, Number 1, https://www.huduser.gov/portal/periodicals/cityscpe/vol22num1/ch12.pdf

Wilson, Ron and Din, Alexander, 2018. “Understanding and Enhancing the U.S. Department of Housing and Urban Development’s ZIP Code Crosswalk Files,” Cityscape: A Journal of Policy Development and Research, Volume 20 Number 2, 277 – 294.

  • Are there other Python packages that accomplish the same thing? If so, how does yours differ?

Not any that I know of.

  • If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted:

NA

Technical checks

For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:

  • does not violate the Terms of Service of any service it interacts with.
  • has an OSI approved license.
  • contains a README with instructions for installing the development version.
  • includes documentation with examples for all functions.
  • contains a vignette with examples of its essential functions and uses.
  • has a test suite.
  • has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.

In terms of vignette, I am assuming you are referring to a Jupyter notebook style documentation. I don't have this, but
there is a website with vignette like documentation: https://etam4260.github.io/hudpy/build/html/index.html

Publication options

JOSS Checks
  • The package has an obvious research application according to JOSS's definition in their submission requirements. Be aware that completing the pyOpenSci review process does not guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS.
  • The package is not a "minor utility" as defined by JOSS's submission requirements: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria.
  • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI:

Note: Do not submit your package separately to JOSS

Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?

This option will allow reviewers to open smaller issues that can then be linked to PR's rather than submitting a more dense text based review. It will also allow you to demonstrate addressing the issue via PR links.

  • Yes I am OK with reviewers submitting requested changes as issues to my repo. Reviewers will then link to the issues in their submitted review.

Code of conduct

P.S. *Have feedback/comments about our review process? Leave a comment here

I feel like there should be a section for details that might not fit into any of the questions above.
Currently my package does not implement caching, but the skeleton code is currently in the module for future
implementation. It will work similar to the caching implemented in the rhud package currently being reviewed by ROpenSci.

I have not looked into the PEP 8 style guide yet, but will make sure to review that.

Editor and Review Templates

Editor and review templates can be found here

@NickleDave
Copy link
Contributor

Hi @etam4260 and welcome to pyOpenSci!

This definitely looks in scope at first glance.
Thank you for filling out the submission in detail.

Let me check in with everyone and we will get back to you by early next week.

@NickleDave
Copy link
Contributor

Hi again @etam4260 sorry for the delayed reply.
Officially, pyOpenSci is on hiatus until fall while we move to a new "home".
@lwasser is about to update the templates and README to make that clear.

But I would really like to get you a review.
I am sure hudpy is in scope, and it would be great to help you make sure it's as good as it can be for the Python community.

Please reply confirming that you would still like to initiate the review process.
Once you do so, I will start finding reviewers.

@etam4260
Copy link
Author

etam4260 commented Jul 9, 2022

Hi @NickleDave, thanks for the response. I've been taking a break from OSS development for a bit. Since I have submitted the rhud package for review, I am still working on changes for those and have not "mapped" over the feedback to the python version. I first would like to work on making those changes before getting formal feedback as I think the reviewers' comments will have a lot of overlap with reviews given so far in the R version. I think in two weeks should be fine. Thanks, again!

@NickleDave
Copy link
Contributor

Makes sense to me @etam4260! Just let us know when you're ready

@lwasser
Copy link
Member

lwasser commented Sep 1, 2022

hey there @etam4260 ! I really appreciate the conversation above and the acknowledgement that you needed a break! I wanted to check back in to see if you are still interested in working through a review with us or if you'd like to wait. IF you would like to wait - no problem. I will close this issue for now, and you can reopen it when you are ready. If you are ready now please just let us know.

Either way we are so happy to have you here at pyOpenSci - just let us know what timeing works best for you. If i don't hear from you within the next week, I will go ahead and close the issue. You can still reopen it at any time.

@NickleDave thank you again for serving as editor here!! 💥

@etam4260
Copy link
Author

etam4260 commented Sep 1, 2022

Hi @lwasser yes, I haven't gotten much time to mess around/revise my work for awhile. No problem. Perfectly fine if this gets closed for now.

@lwasser
Copy link
Member

lwasser commented Sep 1, 2022

ok no problem @etam4260 ! I am going to close this issue with this comment. But please do feel free to resubmit in the future if you find that you have more time to devote to the review process. And keep an eye on pyopensci as we grow the organization and the community. i'm hopeful that we can really help the community of maintainers like you! All the best.

@lwasser lwasser closed this as completed Sep 1, 2022
@lwasser lwasser added the on-hold A tag to represent packages on review hold until we figure out a bigger issue associate with review label Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0/pre-review-checks New Submission! on-hold A tag to represent packages on review hold until we figure out a bigger issue associate with review
Projects
None yet
Development

No branches or pull requests

3 participants