-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
For staging environment, include dynamic text for dandi download
command
#1810
For staging environment, include dynamic text for dandi download
command
#1810
Conversation
dandi download
commanddandi download
command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @aaronkanzer. This looks good to me.
Hi @waxlamp, when you have a chance, this pull request is ready for review. I am not a JavaScript developer so it would be good to have you review. Thank you.
return dandisetIdentifier.value | ||
? `> dandi download ${baseUrl}${dandisetIdentifier.value}/draft` | ||
: ''; // Empty string just as a fallback in case store.dandiset? is undefined | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a good first step since would allow both main and staging one but it is not a generic solution.
The dandi-cli is actually "too smart" to support a wide range of URLs and they do not have to be associated with a specific "short named" instance (if something fails -- it is a bug):
❯ dandi download --help
Usage: dandi download [OPTIONS] [URL]...
Download files or entire folders from DANDI.
Accepted resource identifier patterns:
- DANDI:<dandiset id>[/<version>]
- https://gui.dandiarchive.org/...
- https://identifiers.org/DANDI:<dandiset id>[/<version id>] (<version id> cannot be 'draft')
- https://<server>[/api]/[#/]dandiset/<dandiset id>[/<version>][/files[?location=<path>]]
- https://*dandiarchive-org.netflify.app/...
- https://<server>[/api]/dandisets/<dandiset id>[/versions[/<version>]]
- https://<server>[/api]/assets/<asset id>[/download]
- https://<server>[/api]/dandisets/<dandiset id>/versions/<version>/assets/<asset id>[/download]
- https://<server>[/api]/dandisets/<dandiset id>/versions/<version>/assets/?path=<path>
- https://<server>[/api]/dandisets/<dandiset id>/versions/<version>/assets/?glob=<glob>
- dandi://<instance name>/<dandiset id>[@<version>][/<path>]
- https://<server>/...
so here IMHO it just should use local server URL... chatgpt suggested some code like this
computed: {
baseUrl() {
const protocol = window.location.protocol;
const host = window.location.hostname;
const port = window.location.port ? `:${window.location.port}` : '';
return `${protocol}//${host}${port}`;
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify though -- for example, a user on identifiers.org
though does not see the DANDI CLI download command, so I'm curious why not confine it just to the two specific places where it might render.
I do agree that it could be more generic; however, I'd vote to keep it simple and confined in case an unknown edge case exists (e.g. windoww.location.protocol
is tied to the browser, not Vue, etc., etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a few commits to clean up the PR and change the URL generation to something close to Yarik's ChatGPT code. Check it out and let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify though -- for example, a user on
identifiers.org
though does not see the DANDI CLI download command, so I'm curious why not confine it just to the two specific places where it might render.
sorry, missed the question -- what "two specific places" you have in mind?
here the list of supported URLs organically grown to make it easier for a user to download, e.g. "just cut paste URL from the browser". identifiers.org is indeed niche use case, and would work only for the main instance unless we add some other identifiers to handle in addition to DANDI
. Indeed it is not really needed and likely not really used, but if dandi
is asked to download it and it knows how to parse it -- why not? ;)
Just a note to @aaronkanzer and @kabilar: thanks for contributing this; I'm taking a look. |
This should not cause problems at runtime, as we only ever instantiate this component inside the DLP, where of necessity a dandiset is set. If that assumption fails, we will want to know about it rather than just handing the user a blank command string.
@@ -122,7 +122,7 @@ import CopyText from '@/components/CopyText.vue'; | |||
|
|||
function formatDownloadCommand(identifier: string, version: string): string { | |||
if (version === 'draft') { | |||
return `dandi download https://dandiarchive.org/dandiset/${identifier}/draft`; | |||
return `dandi download ${window.location.origin}/dandiset/${identifier}/draft`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that below for releases, not draft
, we still keep using DANDI:
identifier which would not be correct one. I would have made them also generic and to use ${window.location.origin}/dandiset/${identifier}
even though loosing that nice DANDI:
convenience (well -- could be a matter of a single if
to decide to use DANDI:
if the main instance)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aaronkanzer do you think you would have time to add custom handling below for DANDI:
as well? it is pretty much "use DANDI: if window.location.origin == 'https://dandiarchive.org'", and otherwise needs a ${window.location.origin}/dandiset/
prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated here -- let me know if this is what you had in mind -- thanks again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it looks good.
Should/could we proceed here or any other aspect remains open?
@aaronkanzer ping on above -- could it be considered done?? |
Thanks @yarikoptic. Aaron is out of the office for the beginning of this week. I will touch base with him when he gets back and we can try to close this pull request out this week. |
@yarikoptic works for me -- if you want to approve, I'm happy to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yarikoptic (cc: @aaronkanzer), I think this is ready to go but I had a couple of questions (see the inline comments below).
You can see this in action for a non-dandiarchive URL at the Netlify deploy preview. We will need to deploy to production to see it in action on the canonical dandiarchve.org instance, but it's low risk to do that since it won't disrupt the actual functioning of the archive and we can deploy quick fixes if anything is wrong.
Let me know what you think.
} | ||
|
||
const downloadCommand = computed(() => { | ||
return `dandi download ${window.location.origin}/dandiset/${dandisetIdentifier.value}/draft` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not really follow the discussion in the other thread. Could you summarize here whether this logic is correct for the upload instructions? Is there a reason not to use the same logic as in the download dialog below? Specifically, if a user downloads their dandiset via dandi download DANDI:123456/draft
, will the subsequent dandi upload
command get confused about where to upload?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The DANDI CLI should still be OK -- as @yarikoptic mentioned that any short-hand prefix shouldn't break here, as "The dandi-cli is actually "too smart" to support a wide range of URLs and they do not have to be associated with a specific "short named" instance (if something fails -- it is a bug)"
I can test further if you'd like more confirmation
This sounds good to me, as it won't disturb the API via testing in a prod UI environment -- thanks for the updates here |
Great, then I'll go ahead and merge this and we can still have a discussion about the questions in my self-review above (and do followup PRs in case anything needs to be fixed). Thanks! |
sounds sensible -- let's just try to keep this in memory so we could check as soon as release comes out. Any plans to release soon? |
Oops, I meant to merge this as a release. I'll set up an "empty" PR to trigger a release now. Stand by. |
🚀 PR was released in |
Seems to be working nicely 😸 |
When using
gui-staging.dandiarchive.org
, a minor inconsistency was observed where the CLI command was incorrect.This PR makes a simple fix to render the appropriate text depending on if the user is using staging or production.
Closes #1553
Cc @kabilar