Unpin jupyter server

[ocefpaf]

We no longer need this workaround. The old notebook format is deprecate and we should use either nbclassic or jupyterlab. The pin was added in #134, the docs amended in #135, and this PR is the final step in the old notebook deprecation cycle.

[ocefpaf]

We only build the lockfile for the main env and for these 3 platforms. We are missing ppcle, aarch64, and osx-arm64, only the last two may be worth adding here and it should be possible in the future when the migration we started in conda-forge/conda-forge-pinning-feedstock#4897 finishes.

[ocefpaf]

We are hitting conda-forge/gdal-feedstock#806, let's wait a bit before we retry this PR.

[ocefpaf]

The ERDDAP interpolation notebook, 2021-10-25-ERDDAP-interpolate.ipynb, is failing with a 403 b/c the https://data.pmel.noaa.gov/pmel/erddap server blocked GitHub IPs from accessing it. I did find the same dataset_id on https://erddap.maracoos.org/erddap/tabledap/sd1045_hurricane_2021.html but seems to be a subset of the data in the pmel sever. Our options are:

1. Try to explain to pmel data providers that we need to access their server and see if they can unblock GitHub;
2. Find another server with that data, erddap.maracoos.org is not it though;
3. Change the data and re-write the notebook.

I tried 1 and 2 and failed. I guess we either ask for help or implement option 3.

[MathewBiddle]

Shoot! That's a really neat notebook too. If we can identify a standard gridded dataset that can be made available to that interpolate service, we can make the data available via https://erddap.ioos.us/erddap/index.html

Isn't there another dataset, on another server, that keeps failing and causes headaches for something else? Compliance checker maybe?

[ocefpaf]

Shoot! That's a really neat notebook too. If we can identify a standard gridded dataset that can be made available to that interpolate service, we can make the data available via https://erddap.ioos.us/erddap/index.html

The problem, for now, is the saildrone track served as tabledap in the pmel server. We probably did not get the same ban on the coastwatch one b/c the notebook errors out before reaching it.

Isn't there another dataset, on another server, that keeps failing and causes headaches for something else? Compliance checker maybe?

At this moment, no. I've been changing them to more permissive servers slowly. This one is tricky though b/c I'd really like to keep that particular track. Another option, as we discussed over slack, would be a try/except clause that uses a saved CSV for the saildrone. That would ensure the notebook runs.

[ocefpaf]

And GitHub is also blocked on coastwatch :-/
See https://github.com/ioos/ioos_code_lab/actions/runs/6171167332/job/16748866536?pr=161#step:4:173

Here we cannot cache the data b/c we need to access the server to demonstrate the server side interpolation.

If we can identify a standard gridded dataset that can be made available to that interpolate service, we can make the data available via https://erddap.ioos.us/erddap/index.html

Yep. We will have to change to a server that allows us to use it.

[ocefpaf]

Annnnnd, 15 minutes after changing the server, we are blocked again. See 2473e95 and https://github.com/ioos/ioos_code_lab/actions/runs/6171806691/job/16750780509?pr=161#step:4:173

The first commit with polarwatch was at 7:53, the second one that for us blocked happened at 8:26. This is not OK! Two access, ~30 minutes apart each :-/

[MathewBiddle]

Should we reach out to the admins? They might not know they are blocking these requests...

[ocefpaf]

Should we reach out to the admins? They might not know they are blocking these requests...

I think so. Ever since I started tracking the ERDDAP servers deployments in https://github.com/ocefpaf/ERDDAP_VER_CHECK I observed some odd version downgrades every now and then and I wonder why. Maybe some of those are people who don't know they can set a better policy and are just trying to give users a better experience by downgrading.

[ocefpaf]

Self-merging this to see if I broke the site again or not with #162.