simonw / datasette-app Goto Github PK

I'm going to change that one to Command+O and rename "Open Database" as Command+D.

Right now if you create a new blank database (see #30) you get this on the homepage, which doesn't help explain what is going on:

Split from #45 (I have a working certificate for signing now) and part of #20.

A mechanism for launching multiple windows running against the same Datasette interface would be neat.

Originally posted by @simonw in #13 (comment)

There's an option to create a blank database from #30 but there isn't anything you can do once you've created one.

Currently if you open a new DB file and there are no windows, it opens one.

If you open it and you have an existing open window on the homepage, it refreshes the homepage.

BUT... if all of your open windows are on other pages, nothing appears to happen. This is confusing.

Refs #25 - since I'm going to be installing the plugin dynamically on first launch (and probably allowing the user to upgrade it in the future) it no longer makes sense for the code to live in this repo.

Useful for debugging custom templates needed for #48 - it can go in the Navigate menu.

Split from #7.

Follows #20 and #50 - when I create a release in this GitHub repo it should attach the resulting .zip file to the release.

The new CSV menu item in #29 only works if datasette-app-support [.2 ol higher is installed - but the user may have an older ~/.datasette-app/venv virtual environment running.

So there needs to be some kind of mechanism to notice that the plugin is an unsupported version and upgrade it.

Currently it fails silently and logs to the console.

Something that makes me nervous about this app is that people can install plugins - and I can't guarantee they won't end up installing a malicious plugin that runs malware or steals data or similar.

On macOS it's now possible to lock down apps so they can only interact with their own private "sandbox" folder plus any files that the user explicitly opens using the native file open dialog. This sounds ideal! I can use the sandbox for the virtual environment and install plugins in there, but any malicious plugins (or bugs in my own code) would be limited in how much trouble they could cause.

Researching how to do this with Electron apps is made harder by the fact that Electron has its own sandbox concept which is something completely different - a browser security concept inherited from Chrome.

Follows #25.

Important to get #37 authentication working first - wouldn't want to expose to the network and then have a malicious network entity POST to /-/open-csv-file with a path to a random file on disk so they can read it.

Originally posted by @simonw in #52 (comment)

https://stackoverflow.com/questions/32158738/python-on-electron-framework/39110428#39110428 has a neat looking recipe that uses request-promise - but that's no longer maintained: https://github.com/request/request-promise

Split from #7. Follows #17.

Instead of that nasty timeout.

https://www.electronjs.org/docs/latest/api/browser-window#using-ready-to-show-event

https://github.com/simonw/datasette.app/blob/8a8bee2d2ab8f0a8114e4221d21ea576559666c4/main.js#L16-L24

As a backup plan for if I can't get the PyInstaller one to start in less than 9 seconds (#17 (comment)).

Noticed this after I resurrected the --root option from #32.

It needs to be a thing that users can install on macOS (maybe without it being fully signed, perhaps they have to approve it?) that gives them a working Datasette instance that launches when they launch this application.

This is partly an alternative to #36 where I wanted to share cookies between multiple BrowserWindow instances.

But also... I don't like using --root because it turns on a bunch of confusing tools that are usually intended for debugging. Instead I think datasette-app-support should provide a mechanism for signing the user in as "id": "datasette-app" - then I can use custom permissions to enable things like datasette-upload-csvs without turning on debugging menus for the root user.

Fundamentally, it needs to be able to run against one or more existing SQLite databases.

Originally posted by @simonw in #13 (comment)

1. Bundle a copy of standalone python inside the application folder itself
2. On the first start up, create a virtual environment in ~/.datasette.app/venv using python -m venv with that bundles Python
3. Run bin/pip install datasette in that virtual environment

Originally posted by @simonw in #22 (comment)

I think this would work best, for both CSV and Database file openings using the menu options:

• If there is only one visible window AND it is on the homepage, navigate that to the database page (for open DB) or the new table page (for open CSV)
• Otherwise, open a new window pointing to either that database or that table page

Part of #20

File -> New Database

Can call dialog.showSaveDialogSync({defaultPath: "data.db", title: "Create New Database"}) to bring up a dialog.

Right now there are pages within Datasette (such as the JSON or CSV exports) which provide no way to navigate back out of them - hence it's easy to get stuck:

--setting sql_time_limit_ms and suchlike can be higher for the desktop app than for the default web app.

Can try using https://github.com/http-party/node-portfinder

Would be useful as a shortcut for opening files.

https://www.electronjs.org/docs/api/app#event-open-file-macos suggests this may be possible through listening to the open-file event:

Emitted when the user wants to open a file with the application. The open-file event is usually emitted when the application is already open and the OS wants to reuse the application to open the file. open-file is also emitted when a file is dropped onto the dock and the application is not yet running. Make sure to listen for the open-file event very early in your application startup to handle this case (even before the ready event is emitted).

If I go with the idea in #22 where on first launch a virtual environment is created and Datasette is installed it might be nice to have the blank window show with a loading indicator of some sort.

This will be a good exercise in figuring out how to ship custom CSS with this.

Some tools on macOS get confused by the existence of a datasette.app folder thinking it's an application when it isn't.

Split from #7. Need to do #17 first.

I figured this out in #36 (comment)

+        {
+          label: 'Debug',
+          submenu: [{
+            label: 'Open DevTools',
+            click() {
+              BrowserWindow.getFocusedWindow().webContents.openDevTools();
+            }
+          }]
+        }

Maybe have this available in development but not in production?

Or could keep it in production - or maybe have a secret keyboard shortcut for it?

Can start with something such that if a commit prevents the app from launching entirely the tests fail.

https://python-build-standalone.readthedocs.io/en/latest/building.html#macos

Since I would ideally like Datasette.app to support Python plugins, maybe what I really need is a full-blown Python system tucked away inside the Datasette.app macOS package, with the ability to install extra packages into it?

if so, python-build-standalone could be relevant - it's part of the PyOxidizer project.

Maybe I don't need any of the mechanisms from things like PyInstaller or PyOxidizer that combine my code together into a single executable - I just need to be sure that when a user installs the Datasette.app application it has a guaranteed Python environment that it can use to run datasette and its plugins.

https://twitter.com/tominsam/status/1432892683756867589 and https://daringfireball.net/2009/09/how_should_mac_apps_be_distributed

For the moment I'm going to lock this down so that it's only visible to the current, authenticated use from localhost - but in the future it might be good to have an option for sharing your data by running the server attached to 0.0.0.0 so you can share links with other people on your network.

Originally posted by @simonw in #37 (comment)

For example the "powered by Datasette" link, or URLs in tables that get converted into links.

This is because opening a CSV imports into the temporary in-memory database, and installing a plugin restarts the server.

Could maybe keep track of which CSVs have been opened and re-import them after a restart of the server within the current application session?

Might not be worth fixing this.

See #10 (comment)_

This can work using the Electron file picker open component: https://www.electronjs.org/docs/api/dialog#dialogshowopendialogsyncbrowserwindow-options

It then causes the Datasette process to restart with that file added to the list of arguments.

The first release of this app will have a lot more impact if it can open CSV files. No need for these to be imported into an on-disk SQLite database - they can be opened in memory instead.

File -> Open CSV

Needed for #14 and as a better solution for #3.

Will call datasette install ... (or pip install ...) and then restart the Datasette server.