nextstrain run: third-party pathogen repo support #449

Activity

1. tsibley

   changed the title [-]`nextstrain run`: private pathogen repo support[/-] [+]`nextstrain run`: third-party pathogen repo support[/+] on Sep 17, 2025
2. tsibley commented on Sep 17, 2025

   

   tsibley

   on Sep 17, 2025

   Contributor

   More actions

   Reviewing this again today, I'm leaning towards something like

   nextstrain setup my-pathogen@version=https://github.com/my-org/my-pathogen
   nextstrain setup my-pathogen=https://github.com/my-org/my-pathogen
   
   # maybe even…?
   nextstrain setup https://github.com/my-org/my-pathogen
   

   and special-casing such URLs so we handle them like our repos (i.e. knowing we can interact with them via the GitHub API (well, via nextstrain.org) and not fetching the source from the given URL directly).

   Benefits of this approach:

   1. Provides GitHub preferential treatment (i.e. ease of use), but without excluding preferential treatment for other sources/providers in the future (i.e. like my-org/my-pathogen@version would do).
   2. The URL itself provides a convenient place to specify hard-coded credentials if desired, e.g. https://user:api_key@github.com/my-org/my-pathogen. We would adjust nextstrain version --pathogens --verbose output to mask the secret part of the URL.
   3. It allows for colocating versions of a forked pathogen repo under the same name, e.g. name@nextstrain-version and name@your-version=https://github.com/your/repo (unlike your/repo@your-version).

   I considered the alternative of namespacing, e.g. something like

   nextstrain setup github:your/repo
   

   but I think inventing up prefixes/URLs like that is less clear than using common URLs already out there that people can see in their browser. (There's precedent for this approach in nextstrain remote too.)