Closed mgrauer closed 4 years ago
@mgrauer - perhaps create an issue in the archive and could some list what the bottlenecks would be? it seems that some of this is simply mechanistic in terms of terraform or other setup. i can't image the code changes to be anything but a sed replace. but it would be good to know the timeline.
i suspect we will be asking the same question soon after the schema is updated as well so that our asset download links and other urls point to api rather than publish.
Thank you @mgrauer for the update.
When https://github.com/dandi/redirector/pull/21 gets merged and support for it added to dandi-cli to close #184, nothing would need to be done on dandi-cli
side for any possible future rename of this kind -- it would need to be done in redirector's serve.py for hardcoded value (around https://github.com/dandi/redirector/pull/21/files#diff-5bcee4c3a345db1941bf852ac7ecba6aR15) and just by any deployment (test or whatnot) in its specification. I am not sure if it is worth tracking here for this reason, so I will close this issue since nothing to be done on client side IMHO.
In the longer run we need to workout "deployment" configuration which probably would be fed into redirector and any relevant component (avoiding any possible hard-coding which now might be present). Client should be informed about any relevant service endpoints by the deployment it would be talking to, and that is what aforementioned issues are trying to achieve.
@yarikoptic had asked in a meeting earlier today if we could shift publish.dandiarchive.org to api.dandiarchive.org, and after some discussion, we won't be able to make that move in the next week, so it can't be done near term to align with the CLI release of 0.6.0.
I'm logging this issue in CLI for longer term tracking, but also as a way of communicating the answer to that earlier question--I'm not sure if an issue is the best way to communicate this, but at least it will reach you and save the need for the future.