search

darthoctopus / pyneapple

Fork of Nathan Whitehead's Pineapple, rewritten entirely in Python3
GNU General Public License v3.0
1 stars 0 forks source link

Any plan on continuing developing? #4

Open otaj opened 3 years ago

otaj commented 3 years ago

Hi,

are there any plans on continuing developing this project? I am a big fan of native desktop applications (as opposed to Electron stuff, or browser "pages") and would love to see more development on this.

If there is no more plan, I will probably switch permanently to using VSCode.

If you would some help on this, I might be able to provide some, as I am fairly proficient in Python, however I don't have much experience with GUIs

Thanks a lot for awesome project!

darthoctopus commented 3 years ago

Hi,

Thanks for reaching out! I'm still using pyneapple myself on a regular basis. I think the lack of updates is because I've basically reached the feature set that I find myself needing day to day, and haven't personally felt much of an urge to add more (if it ain't broke don't fix it). I welcome suggestions for new features!

Best regards, Joel Ong

On Tue, Feb 16, 2021 at 06:53, otaj notifications@github.com wrote:

Hi,

are there any plans on continuing developing this project? I am a big fan of native desktop applications (as opposed to Electron stuff, or browser "pages") and would love to see more development on this.

If there is no more plan, I will probably switch permanently to using VSCode.

If you would some help on this, I might be able to provide some, as I am fairly proficient in Python, however I don't have much experience with GUIs

Thanks a lot for awesome project!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

otaj commented 3 years ago

Damn, that was fast!

I sometimes have issue with Pyneapple to pick up kernels (some are installed system-wide, some only for a user and some are installed by anaconda), but I gotta admit, I don't use Pyneapple as often as I used to lately, so cannot really comment on it. But, just for the context of how much was I using it, I am the guy who packaged it for AUR (in issue #3 ) :)

One feature that I would absolutely love and would make it a number one for me would be support for remote kernels (specifying address with a token/password, and even better, supporting remote Jupyter Lab, which would then be able to use any kernel installed on the Lab instance) + some form of linting :) But those are just wet dreams :)

darthoctopus commented 3 years ago

Picking up kernels seems to be to be a documentation issue. Pynapple uses custom jupyter config and data directories, which may not necessarily agree with the system ones. If you want to use the same kernels everywhere, consider symlinking ~/.local/share/pyneapple/data/kernels to ~/.local/share/jupyter/kernels. If you use notebook extensions, you might also want to do this for the nbextensions directory.

Remote kernels might be a little difficult, since presently the way the GTK side of things interacts with the notebook itself is via callback scripts loaded to a custom scripts directory when starting the notebook server. This means that you will need to be able to use a custom scripts directory on the remote server — I imagine also that things like theming may not work 100%. However if you're fine with needing some initial setup on the remote server, and losing other features (e.g. filepicker dialogue for saving/renaming), I think a remote-server view is entirely feasible. Does that sound like something you would use?

Linting sounds like it might be best handled with a notebook extension or external utility. Personally I open a terminal window with ctrl-alt-T and run nblint. Do you have suggestions for an inline linter?

I don't use jupyterlab, so I'm not sure how much effort it would entail. My impression is that the custom GUI widgets of Lab (in particular the document menu) function similarly to notebook. I think a lot of Nathan's techniques (activating menu items with DOM controls) should remain broadly applicable; I imagine the majority of the effort would be just writing wrappers.

On Tue, Feb 16, 2021 at 07:05, otaj notifications@github.com wrote:

Damn, that was fast!

I sometimes have issue with Pyneapple to pick up kernels (some are installed system-wide, some only for a user and some are installed by anaconda), but I gotta admit, I don't use Pyneapple as often as I used to lately, so cannot really comment on it. But, just for the context of how much was I using it, I am the guy who packaged it for AUR (in issue #3 ) :)

One feature that I would absolutely love and would make it a number one for me would be support for remote kernels (specifying address with a token/password, and even better, supporting remote Jupyter Lab, which would then be able to use any kernel installed on the Lab instance) + some form of linting :) But those are just wet dreams :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

darthoctopus commented 2 years ago

I've now implemented some rudimentary support for remote notebooks. This is done by way of a custom URL handler to accommodate token authentication. In particular, if you have a jupyter server at http://<server>/?token=asdf..., you can now access it by replacing http:// with pyneapple://, which will open up a simple webview to the notebook server homepage; clicking a link to any notebook will open a notebook viewer window. Currently themes aren't supported (since those depend on files in the custom js folder), but autodetection of kernels should work. Note that some features are broken --- in particular the open/save-as features don't work (since the local file pickers don't really make sense here), nor do the open-folder and open-terminal actions.