Hackathon: 2024-02-20

[mfisher87]

Please create a new comment (at the very bottom, use the text box with a button that says "comment", not "reply") to write about what you did today!

Please include links to GitHub issues or pull requests relevant to your work, and use those issues or pull requests as the "source of truth" for documenting the work; this makes future readers jobs easier :) It's OK to duplicate some information while writing a summary here!

Use the "reply" feature to have a discussion under any given comment.

[mfisher87]

For demonstration purposes, this is a comment

[mfisher87]

This is a reply!

[danielfromearth]

Today, @mfisher87 and I discussed ways to approach new tests to be added for the User Acceptance Testing (UAT) Earthdata environment feature, PR #426. This included discussion of integration vs. unit tests (which resulted in this new issue), where to place unit tests in the package structure, and shared learning about test/function mocking.

[mfisher87]

From reading other tests, we learned about a new-to-us tool called responses which seems to make mocking requests much simpler than normal. Cool! And a great name.

[asteiker]

@nikki-t @betolink @jhkennedy @mjami00 @JessicaS11 @jpswinski and I discussed the architecture surrounding #328 and the specific Harmony service discovery needs per #447 . @mjami00 demonstrated a GEDI Harmony subsetting notebook that included the creation of a json containing GEDI variables to help users identify which variables to subset. We then explored the Harmony capabilities endpoint using an example of collection with Harmony services (https://harmony.earthdata.nasa.gov/capabilities?collectionId=C1598621093-GES_DISC) and a collection without services (https://harmony.earthdata.nasa.gov/capabilities?shortname=ATL06). In terms of how to break down this work:

• Step 1: List available services through CMR
• Step 2: For those services, provide to users: here’s what those capabilities are.
  • Start with Harmony plugin; use their capabilities endpoint, figure out how to surface that in earthaccess
  • Also think about how to make it like an xarray way of representing CMR metadata (like a fake dataset)

[JessicaS11]

@mjami00's notebook inspired me to explore using icepyx's Variables module for GEDI. I'm excited to report back that my initial exploration got me from zero to a list of beams/variables very quickly. I put together a short demo notebook showing how - in a few lines - we can use icepyx.Variables to create a list of GEDI beams/variables. I'm excited to keep exploring ways we can generalize and share this type of tooling!

[stefaniebutland]

Matt @mfisher87 demonstrated how to set up your development environment to contribute to earthaccess documentation
12-min live demo on YouTube

[rupesh2]

Very useful! Thanks, @mfisher87! Following are my notes from Matt's YouTube video (sharing for those like me who find it easier to read than watch :) )).

• Clone the repo: git clone [email protected]:nsidc/earthaccess.git
• Change directory: cd earthaccess\binder
• Create conda environment: conda env create -f environment-dev.yml. If you see a warning that the environment already exists, do conda env remove -n earthaccess-dev
• Activate conda: conda activate earthaccess-dev
• Install packages : pip install --editable .
• Change to the base directory. cd ..
• Run lint script: ./scripts/doc-live.sh
• On your browser, go to: https://localhost:8008
• You can now change any pages in the docs or codes in your text editor, which will instantly reflect in the browser.
• Check git status to see what changed: git status
• Create a new branch: git switch -c "test"
• Add changes: git add .
• Commit changes: git commit -m "Add some examples changes to demo the docs workflow"
• Push changes: git push -u origin test
• Now, if you go to https://github.com/nsidc/earthaccess, you can see the workflow in the "Actions" tab.

[mfisher87]

Awesome write-up, thank you so much for this @rupesh2 ! Would you be willing to open a pull request to add a page to our documentation with this information (CONTRIBUTING.md I think)?

One thing to note that's very important: most folks won't have permissions to push directly to this repository. I did because I'm a maintainer, and arguably even then it would be a better practice to fork. I was rushing to fit everything in 10 minutes, but I should definitely have mentioned this! :) Following these instructions directly without permissions will result in an error. But that's OK because you can recover, and I'll write about that at the bottom.

Changes to work with a fork

I would suggest adding the following steps so the instructions can be more universal:

• Fork earthaccess in the GitHub user interface to create your own copy.
  • Later on, you may need to sync your fork with the original repository. This can also be done in the GitHub UI. If you get stuck, the emergency escape hatch is to take a fresh fork again! :)
• Clone the repo: git clone [email protected]:<yourusername>/earthaccess.git

... everything else is the same. Until this one, which should be removed:

• Now, if you go to https://github.com/nsidc/earthaccess, you can see the workflow in the "Actions" tab.

And instead:

• Open a pull request in the GitHub user interface from your fork to the original nsidc/earthaccess repo. When you ran git push in a previous step, it provided a convenient link to directly open that PR.
• In the PR interface, you can view the progress of the GitHub Actions workflows specific to the PR at the bottom of the page.

Recovering from following the above instructions and being met with a permissions error

One option is to request permissions. We'd love more folks on the maintenance team! If you're willing, just let us know. There is no specific time commitment, the only commitment is to adapt to a common workflow. If you're interested ping myself, @betolink, @asteiker, or anyone else on the maintenance team.

The other option is:

• Create a fresh fork of earthaccess in the GitHub user interface
• Add fork as a remote: git remote add <remotename, e.g. your username> <fork repository HTTPS/SSH URL>
• Push to the fork: git push -u <remotename> <branchname>
• Now you should be able to open a PR using the GitHub user interface or by following the link returned after the git push command.

TODO: Screenshots / docs links for all of the above mentions of "...in the GitHub user interface..."

Do we want to try and record a more comprehensive demo that includes forking?

[rupesh2]

@mfisher87 thank you for your guidance ! I will add the fork and other suggestions you mentioned and submit a pull request (my first to earthaccess). Thank you!

[mfisher87]

@rupesh2 that's fantastic, thank you! My pleasure to help; if there's anything more I can do please don't hesitate to @ me on GitHub or Openscapes Slack :)

[andypbarrett]

@andypbarrett started to update and reorganize documentation with the initial focus on the "Overview" page.

See: https://github.com/nsidc/earthaccess/tree/update-documentation