Add an option for loading an api key

[griff-rees]

The flexibility of a URL is great, but they'd prefer API keys were in the header: https://www.zotero.org/support/dev/web_api/v3/basics

Any chance an option following their API and mkdocs environmental variable options could be added, something like:

- bibtex:
    bib_file:
      zenodo: true
      zenodo_user_or_goup_id: !ENV [A_SYSTEM_VAR, ZENODO_GROUP, "1234567"]  # Zenodo group ID number
      zenodo_api_key: !ENV [ANOTHER_SYSTEM_VAR, A_GITHUB_ENV, ZENODO_API_KEY]

to fill in this sort of template:

https://api.zotero.org/groups/${zenodo_user_or_group_id}/items?format=bibtex&key=${zenodo_api_key}

A slicker option could use pyyaml-env or python-dotenv to use a local .env like:

ZENODO_GROUP=1234567
ZENODO_API_KEY=12345671234567

but that might be a feature request for mkdocs generally. That was mentioned in this ticket but as best I understand only environmental variables were added via pyyaml-env-tag (hence the documentation linked above which follows the same format).

[shyamd]

Hmmm interesting issue.

This seems like a feature request, correct? You're currently able to use a URL with an API key in it. If you want to keep that API key secret, you can use the Environment Variable capability of mkdocs to keep the whole URL in your CI/CD secrets.

It sounds like the add would be custom integration for Zenodo's API. Although, I'm also not sure Zenodo's stated issue is actually a problem for this plugin. It doesn't use any pagination, just a straight pull of the whole bibtex "file".

[griff-rees]

Yeah feature request is the best summary but... probably makes more sense to split it into multiple components. Apologies for intertwining.

• Ease of authentication, especially as the documentation prefers a header rather than the key in the url.
• Managing API pagination: there is actually a default limit of 100, which can be extended to 150 (ran into that problem myself) but no further, so in theory iterating over all. FYI: both overleaf and betterbibtex have means of getting around pagination.
• Perhaps more generally: exposing a way of more easily providing a callable and kwargs for an API (Zotero or otherwise...).

[shyamd]

Unfortunately none of these are simple and I'm hesitant to support them directly since I'm not using this plugin myself currently.

The big issue is that there's no standard way of dealing with these issues across services. Each will have it owns methods and constraints.

I'd say the best way to implement all of these would be to run your python script first that grabs the bibtex, dealing with authentication and pagination as necessary. If you're building as part of a CI/CD pipeline, which you should, then its just a step before the mkdocs build step.

[griff-rees]

I figured this was already a bit much. Perhaps a variation of the mkdocs issue I linked above to ease use of a local .env file that can then be overridden with GitHub env variables is a much more general solution to this and other issues of this ilk.

FYI: I may have a more specific ticket to raise on the cite_inline option. Hoping it's just an issue on my part but my config's already pretty complicated so need to start fresh to reproduce. Hopefully other deadlines will calm down so I can give that a go. Thanks for the detailed responses.