issue_comments

Getting this to work with both Sanic AND ASGI at the same time (via the classes described previously with an --asgi command-line option) is proving way trickier than I expected, mainly because of the complexity of the current Datasette.app() method.

I'm going to drop the compatibility path for a bit and see if I can make progress on a pure-ASGI port.

I'm going to resist the temptation to do this until I've merged the asgi branch from #272

This test added do test_black.py seems to do the trick: python @pytest.mark.parametrize("path", code_root.glob("**/*.py")) def test_isort(path): # Have to capture stdout because isort uses print() directly stdout = sys.stdout sys.stdout = io.StringIO() result = isort.SortImports(path, check=True) assert ( not result.incorrectly_sorted ), "{} has incorrectly sorted imports, fix with 'isort -rc . && black .'" sys.stdout = stdout I'll rename test_black.py to test_lint.py to reflect that it now covers more forms of linting.

Also needed: add move_to_front(items, "test_isort") to conftest.py. And add isort to extras_require in setup.py.

According to the black documentation the following config file is necessary to avoid isort and black getting into an edit war with each other: [settings] multi_line_output=3 include_trailing_comma=True force_grid_wrap=0 use_parentheses=True line_length=88

I'd rather not turn this into a systemd support thread, but you're trying to execute the package directory there. Your datasette executable is probably at /home/chris/Env/datasette/bin/datasette.

WorkingDirectory=/path/to/data

@russss, Which directory does this represent?

It's the working directory (cwd) of the spawned process. In this case if you set it to the directory your data is in, you can use relative paths to the db (and metadata/templates/etc) in the ExecStart command.

In my case, on a remote server, I set up a virtual environment in /home/chris/Env/datasette, and when I activated that environment I ran pip install datasette.

My datasette project is in /home/chris/datatsette-project, so I guess I'd use that directory in the WorkingDirectory parameter?

And the ExecStart parameter would be /home/chris/Env/datasette/lib/python3.7/site-packages/datasette serve -h 0.0.0.0 my.db I'm guessing?

WorkingDirectory=/path/to/data

@russss, Which directory does this represent?

It's the working directory (cwd) of the spawned process. In this case if you set it to the directory your data is in, you can use relative paths to the db (and metadata/templates/etc) in the ExecStart command.

WorkingDirectory=/path/to/data

@russss, Which directory does this represent?

This example is useful to - I like how it has a Makefile that knows how to set up systemd: https://github.com/pikesley/Queube

I wasn't even aware it was possible to add a systemd service at an arbitrary path, but it seems a little messy to me.

Maybe worth noting that systemd does support per-user services which don't require root access. Cool but probably overkill for most people (especially when you're going to need root to listen on port 80 anyway, directly or via a reverse proxy).

This example is useful to - I like how it has a Makefile that knows how to set up systemd: https://github.com/pikesley/Queube

Here are some partial notes I have saved from an nginx configuration I've used in the past: ``` cat /etc/nginx/sites-available/default server { listen 80 default_server; listen [::]:80 default_server;

    location / {
            proxy_pass http://127.0.0.1:8001/;
    proxy_set_header Host $host;
    }

... ```

... and @russss also suggested systemd 21 seconds before I posted that!

I asked about this on Twitter and got a solid recommendation for systemd and this tutorial: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units - via https://twitter.com/sil/status/1142412145990221825

On most modern Linux distros, systemd is the easiest answer.

Example systemd unit file (save to /etc/systemd/system/datasette.service): ``` [Unit] Description=Datasette After=network.target

[Service] Type=simple User=<username> WorkingDirectory=/path/to/data ExecStart=/path/to/datasette serve -h 0.0.0.0 ./my.db Restart=on-failure

[Install] WantedBy=multi-user.target ```

Activate it with: bash $ sudo systemctl daemon-reload $ sudo systemctl enable datasette $ sudo systemctl start datasette

Logs are best viewed using journalctl -u datasette -f.

This is also relevant to Datasette Library #417

A section in the Datasette docs that acts as recommendations plus a tutorial for running Datasette on a VPS without using a Docker would be excellent.

I'm still trying to figure this out myself.

I'm confident that running nginx on port 80 and using it to proxy traffic to Datasette is a sensible way to solve the port problem.

As for running Datasette itself: the two options that seem best to me are some kind of Init.d service or running it under supervisord. I have to admit I haven't worked out the necessary incantation for either of those yet: the solitary instance I have that's not running as a Docker container is sitting in a "screen" instance for the moment!