Upload to current working directory

[juntyr]

Supersedes #23

Upload the repository to the current working directory instead of the root.

Since this extension is loaded at startup, it should not cause any change in behaviour. However, it enables additional usecases such as jupyterlite/jupyterlite#1518

[github-actions]

👈 Launch a Binder on branch juntyr/litegitpuller/patch-1

[juntyr]

What are your thoughts on this change @brichet @jtpio?

[brichet]

Thanks @juntyr.

Can you provide an example on how to test it ?
On my side the directory is still created in root, even if I provide a path in the URL. The extension seems to be activated before the path is updated in the file browser.

[juntyr]

How do you provide a path in the URL? This may indeed come down to extension scheduling and it would be worth checking that this extension runs after the one that provides the navigation on startup.

I’ve been working on a custom extension (one JupyterLite server extension and one JupyterLab front end extension) that create a new folder as early as possible (in the sever extension) and navigate to it as soon as possible (I read that fronted extensions are activated alphabetically - once their dependencies are satisfied). My hope is that this way the file system path is changed before litegitpuller reads it.

[brichet]

How do you provide a path in the URL?

In jupyterlab /tree/mypath and in lite ?path=mypath works

I read that fronted extensions are activated alphabetically

I didn't know that, I would be interested for the source if you have it. Otherwise we can still check in the code base.

That said, the change in this PR looks good to me, but maybe we should ensure this will be usable before including it.

[brichet]

I read that fronted extensions are activated alphabetically

AFAIK, except if there is an explicit dependency, extensions don't wait for each other.
This means that even if the extensions are alphabetically activated, there is no way to control that an extension if fully activated before another start without explicit dependency.

[juntyr]

I think https://github.com/jupyterlite/jupyterlite/blob/main/packages/application-extension/src/index.tsx#L369 is the issue - it waits until the app is started (all extensions have activated) before changing the path that’s supplied in the URL

[juntyr]

I read that fronted extensions are activated alphabetically

AFAIK, except if there is an explicit dependency, extensions don't wait for each other. This means that even if the extensions are alphabetically activated, there is no way to control that an extension if fully activated before another start without explicit dependency.

Yes that’s true. We could perhaps also wait until the app has started in litegitpuller and then check the cwd again and it necessary move the upload folder there. But even this would be fimble. What we’d really need is for litegitpuller to have an optional dependency on a token that may be provided by any plugin and that signals that the default path has changed. Is this possible?

[brichet]

What we’d really need is for litegitpuller to have an optional dependency on a token that may be provided by any plugin and that signals that the default path has changed. Is this possible?

I don't know what is the "default path". Do you mean the path of the default filebrowser ?

If I understand correctly your need, an other (simplest ?) option could be to add an optional URL parameter with the destination directory. That parameter could be used to create the directories (if necessary) before pulling the repo there.

[juntyr]

I meant the path that is opened in the filebrowser when JupyterLite loads so that the upload is immediately visible.

In my use case, the path is dynamically determined and created at launch time. I thought that telling the file browser to change to this fresh directory was the cleanest option.

Other uploads also are placed into the currently selected file system directory, so if this change is possible to implement it would make the behaviour more aligned with other uploads.

[juntyr]

If I understand correctly your need, an other (simplest ?) option could be to add an optional URL parameter with the destination directory. That parameter could be used to create the directories (if necessary) before pulling the repo there.

I've thought about it again and that should indeed work! I've opened #26 to supersede this PR - thanks for the feedback!