Skip to content
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

Merged
merged 9 commits into from
Sep 20, 2024

Conversation

aaronkanzer
Copy link
Member

@aaronkanzer aaronkanzer commented Jan 11, 2024

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

@aaronkanzer aaronkanzer changed the title For staging environment, Include dynamic text for dandi download command For staging environment, include dynamic text for dandi download command Jan 11, 2024
@kabilar kabilar requested a review from waxlamp January 13, 2024 02:02
Copy link
Member

@kabilar kabilar left a 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
});
Copy link
Member

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}`;
  }
}

Copy link
Member Author

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.)

Copy link
Member

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.

Copy link
Member

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? ;)

@waxlamp
Copy link
Member

waxlamp commented Feb 23, 2024

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`;
Copy link
Member

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)

Copy link
Member

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

Copy link
Member Author

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

Copy link
Member

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?

@yarikoptic
Copy link
Member

@aaronkanzer ping on above -- could it be considered done??

@kabilar
Copy link
Member

kabilar commented Sep 10, 2024

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.

@waxlamp waxlamp self-assigned this Sep 10, 2024
@aaronkanzer
Copy link
Member Author

@yarikoptic works for me -- if you want to approve, I'm happy to merge.

Copy link
Member

@waxlamp waxlamp left a 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`
Copy link
Member

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?

Copy link
Member Author

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

@aaronkanzer
Copy link
Member Author

@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.

This sounds good to me, as it won't disturb the API via testing in a prod UI environment -- thanks for the updates here

@waxlamp
Copy link
Member

waxlamp commented Sep 20, 2024

@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.

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!

@waxlamp waxlamp merged commit 117b7ef into dandi:master Sep 20, 2024
4 checks passed
@yarikoptic
Copy link
Member

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.

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?

@aaronkanzer aaronkanzer deleted the aaronkanzer-staging-command branch September 20, 2024 16:24
@waxlamp
Copy link
Member

waxlamp commented Sep 20, 2024

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.

@dandibot
Copy link
Member

🚀 PR was released in v0.3.102 🚀

@dandibot dandibot added the released This issue/pull request has been released. label Sep 20, 2024
@waxlamp
Copy link
Member

waxlamp commented Sep 21, 2024

Seems to be working nicely 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released This issue/pull request has been released.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

For empty dandiset listing upload instructions, make them use instance URL not the main one
5 participants