jupyterlab-desktop
jupyterlab-desktop copied to clipboard
jupyterlab
Apple developer program certificates
Linux and Windows distribution work, but it's hard to distribute apps for MacOS without apple certificates. https://developer.apple.com/programs/
This is going to require a legally registered entity, I imagine NumFocus
I can take care of the apple certs
On Fri, Jul 14, 2017 at 12:09 PM, Davide Bortolami <[email protected]
wrote:
Linux and Windows distribution work, but it's hard to distribute apps for MacOS without apple certificates. https://developer.apple.com/programs/
This is going to require a legally registered entity, I imagine NumFocus
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab_app/issues/68, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0AeGl_2ltIfjiDIjmUIUMXTLfrEVks5sN7zegaJpZM4OYoHn .
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
I have taken the initial steps and will report back!
On Fri, Jul 14, 2017 at 2:00 PM, Brian Granger [email protected] wrote:
I can take care of the apple certs
On Fri, Jul 14, 2017 at 12:09 PM, Davide Bortolami < [email protected]> wrote:
Linux and Windows distribution work, but it's hard to distribute apps for MacOS without apple certificates. https://developer.apple.com/programs/
This is going to require a legally registered entity, I imagine NumFocus
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab_app/issues/68, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0AeGl_2ltIfjiDIjmUIUMXTLfrEVks5sN7zegaJpZM4OYoHn .
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
I think we might push this to the 0.2 release milestone to give some more time to @ellisonbg , considering the first users will mostly be experienced users we can give the instructions to run untrusted sw
@ddavidebor @ellisonbg I just talked to Natasha about this. We're going to push the 0.1 release date to next Tuesday (8/1) with the following features:
- Frameless window with native menu bar.
- Persistent application state.
- Packaged application without apple developer certs.
- Ability to spawn local Jupyter servers.
- Basic keyboard shortcuts.
We're going to disable all the unstable features like server management. We want a couple days to push the code into a more stable state, but we both feel comfortable with that date.
I'll create a release on the Github releases page with five downloads beyond the source code: mac dmg, deb file, rpm file, AppImage, and Windows package. Mac users will not be able to run the packaged app without disabling security features.
+1
On Fri, Jul 28, 2017 at 12:37 PM, Davide Bortolami <[email protected]
wrote:
Great!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab_app/issues/68#issuecomment-318743775, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0D26PjiOCBxj0nFkh-BBKf73T59-ks5sSjhfgaJpZM4OYoHn .
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
We're still trying to sort out some bugs with the keyboard shortcuts and the frameless window. We're pushing the 0.1 release back until tomorrow (8/2).
Sounds good!
On Tue, Aug 1, 2017 at 5:59 PM, Natasha Proctor [email protected] wrote:
We're still trying to sort out some bugs with the keyboard shortcuts and the frameless window. We're pushing the 0.1 release back until tomorrow (8/2).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab_app/issues/68#issuecomment-319538325, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0D643-_xOpPAMQj6Va5NUmvyr0Gfks5sT8oCgaJpZM4OYoHn .
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
@ellisonbg Everything's going well with the apple certificate ? Please let me know if there is anything I can do
OK I have created the certificates and can help do this during the next release cycle. For reference here are some docs on this process:
https://github.com/electron-userland/electron-osx-sign/wiki/1.-Getting-Started
@ellisonbg These are the instructions for electron-builder https://www.electron.build/code-signing (it already uses electron-osx-sign under the hood)
This is how SUSE Rancher Kubernetes Desktop has solved the electron Microsoft code-signing for their opensource project: https://github.com/rancher-sandbox/rancher-desktop/pull/405
Is signing and notarizing the app for Apple still on the to-do?
With the recent macOS updates, it is getting more restrictive to install things that are not signed. It would be a better user experience either way.
I am happy to help if needed.
I believe @mbektas already completed this. @mbektas do you have an update on this front? Can we close the issue?
I downloaded the installer yesterday and when I ran it, the popup showed up on macos monterey 12.1 / apple silicon chip.
@ellisonbg the PR is still in draft: https://github.com/jupyterlab/jupyterlab-desktop/pull/318
hi everyone, I was able to code sign the application binaries for Mac properly in this PR https://github.com/jupyterlab/jupyterlab-desktop/pull/318. However, I had issues signing the installer package binary (.pkg) file. It seemed to require a different signing certificate (Developer ID Installer certificate) than the contained JupyterLab Desktop binaries. I didn't get chance to work on that yet unfortunately. I am hoping so get back to it in the coming weeks.
The installer really should be ditched in favor of a portable app bundle. One of the first things I did after installing was move the app to a better location, which instantly broke it. The installer creates tons of files with hard-coded absolute paths in the app bundle-- really bad practice. The app should be portable and sandboxed, discovering paths relative to the app bundle at runtime.
Furthermore, installers should be avoided in general because they can mess with parts of a system that an app shouldn't have access to. Every time I come across an app distributed as an installer, I immediately distrust it. There are very few legit reasons to require an installer.
Edit: If the hard coded paths (conda envs and such) can’t be reasonably made portable, they should instead exist in ~/Library/Application Support/jupyterlab-desktop/. Actually, that’s more consistent with macOS anyway. Deleting the app’s preferences and application support should result in a virgin app. Anyway, the app should generate the initial environment, not an installer.
Do you have a recommendation William?
Options: https://en.m.wikipedia.org/wiki/Portable_application_creators
On Tue, Feb 15, 2022, 10:55 PM William Knop @.***> wrote:
The installer really should be ditched in favor of a portable app bundle. One of the first things I did after installing was move the app to a better location, which instantly broke it. The installer creates tons of files with hard-coded absolute paths in the app bundle-- really bad practice. The app should be portable and sandboxed, discovering paths relative to the app bundle at runtime.
Furthermore, installers should be avoided in general because they can mess with parts of a system that an app shouldn't have access to. Every time I come across an app distributed as an installer, I immediately distrust it. There are very few legit reasons to require an installer.
— Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab-desktop/issues/68#issuecomment-1041076383, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABF6LZWXVKGHVLR7MVLDI7LU3MN2RANCNFSM4DTCQHTQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
I'm not familiar with the portable application creators that you linked, though it sounds like they encapsulate the app in a virtual machine or docker container or the like. I don't think that's necessary in this case, but there could be advantages. If something like that is desirable it would have to be carefully considered by the project leaders.
As far as a simpler solution goes, I had a peek at the build system a bit and it looks like the install scripts could basically be adapted to be part of the app's initial run, targeting Application Support rather than the app bundle. It didn't seem like large changes would be necessary.
My question is: Was the current installer and app bundle a deliberate design decision, and, if so, what were the tradeoffs that were considered? Also, should I create a separate issue for this?
Looking into the simple solution a bit further, conda constructor does not currently support whitespaces in paths (e.g. "~/Application Support/jupyter-desktop/"). The good news is that it would be fixed by https://github.com/conda/constructor/pull/449, which looks to be close to merge ready.
~~As an aside, since this is a desktop app, I think it would be nice if the app environment(s) were completely isolated from the system environment using containers that could be managed by the app. Currently if you have widgets installed, the same versions of those widgets must be installed in (1) the environment jupyterlab-desktop was started with, and (2) any conda envs or kernels that use said widgets. Trying out widgets and managing envs and widgets is somewhat awkward and very confusing if something goes wrong. It's a different issue for sure, but going that route could also ensure app bundle portability.~~
Edit: Encapsulating the app environments could be challenging to implement and also end up confusing to users. A more reasonable solution for widget management awkwardness would be to just implement an extension manager in jupyterlab-desktop (which already exists for jupyterlab)-- discussed in https://github.com/jupyterlab/jupyterlab-desktop/issues/269.
Anyway, to reiterate, the simple approach to ensuring app bundle portability is: once https://github.com/conda/constructor/pull/449 is merged, (1) target the env install to "~/Application Support/jupyterlab-desktop/jlab_server/", and (2) ditch the installer and have the app itself run the env_installer script if no env is found (e.g. on first run).
The good news is that it would be fixed by https://github.com/conda/constructor/pull/449, which looks to be close to merge ready.
The unfortunate problem with this is that that PR has been open for coming up on a year now and Anaconda has taken no interest in it. My team has also been waiting to see it fixed and in the meantime we went with just banning anyone from installing our software somewhere with a space in it :/
The good news is that it would be fixed by https://github.com/conda/constructor/pull/449, which looks to be close to merge ready.
The unfortunate problem with this is that that PR has been open for coming up on a year now and Anaconda has taken no interest in it. My team has also been waiting to see it fixed and in the meantime we went with just banning anyone from installing our software somewhere with a space in it :/
FYI, that PR was finally merged 4 months ago. Maybe conda now supports spaces in file names-- welcome to 2023!