issue_comments

The other way this could work is passing a single argument - the file (or directory) to be copied in - and assuming it should always go in the /app root. Something like:

datasette publish cloudrun my.db --include src/ --include dogsheep-beta.yml

Which would add /app/src/... and /app/dogsheep-beta.yml.

I can't just use COPY /path/to/blah.yml /app in the Dockerfile because it runs on the Google Cloud Build servers, not on the user's laptop - so I need to first copy the files they specify to that temporary directory that gets uploaded to the cloud, then rewrite the COPY lines in the Dockerfile to copy from there.

But since we're already running COPY . /app anything that's made it into the temporary directory will get copied into /app.

But... I feel the usability of the command will be better if users can use absolute paths on the target side:

datasette publish cloudrun my.db --cp dogsheep-beta.yml /app

Note that datasette publish cloudrun uses a working directory of /app - so users will need to copy their files into /app if that's where they need to live.

https://github.com/simonw/datasette/blob/17cbbb1f7f230b39650afac62dd16476626001b5/datasette/utils/init.py#L348-L357

I filed a new public bug in their issue tracker here: https://github.com/vercel/vercel/issues/5575

This is a really frustrating bug with Vercel: https://github.com/simonw/datasette-publish-vercel/issues/28

+ characters in URLs get translated into spaces before they get to Datasette. They know about the bug and said they were working on a fix a few months ago, but looks like it's still a problem.

A workaround is to avoid + and use - instead - I think this SQL query does the same thing as yours:

https://aws-partners-singapore.vercel.app/partners?sql=select%0D%0A++A.launch_rank%2C%0D%0A++A.partner_info%0D%0Afrom%0D%0A++summary+A%0D%0A++INNER+JOIN+summary+B+ON+A.launch_rank+%3E%3D+B.launch_rank+-+3%0D%0A++AND+A.launch_rank+-4+%3C%3D+B.launch_rank%0D%0AWHERE%0D%0A++B.%22partner_info%22+LIKE+%27%25Palo+Alto%25%27

sql select A.launch_rank, A.partner_info from summary A INNER JOIN summary B ON A.launch_rank >= B.launch_rank - 3 AND A.launch_rank -4 <= B.launch_rank WHERE B."partner_info" LIKE '%Palo Alto%' I've been moving projects from Vercel to Cloud Run when they run into this, but that's not a great situation to be in.

It turns out I need this for a couple of projects:

• datasette-ripgrep needs to ship a whole bunch of source code files up in a known location. I worked around this with a nasty hack involving --static but it would be better if I wasn't doing that.
• dogsheep-beta uses an additional dogsheep-beta.yml configuration file in the project root (a sibling to metadata.yml) which needs to be included when publishing - see https://github.com/simonw/datasette.io/issues/21#issuecomment-747058067

I want this for datasette publish cloudrun, not just for datasette package.

I'm just going to add q for the moment.

Should I pass any other details to the display_sql here as well?

To do this I'll need the search term to be passed to the display_sql SQL query: https://github.com/dogsheep/dogsheep-beta/blob/4890ec87b5e2ec48940f32c9ad1f5aae25c75a4d/dogsheep_beta/init.py#L164-L171

I think I can do this as a cunning trick in display_sql. Consider this example query: https://til.simonwillison.net/tils?sql=select%0D%0A++path%2C%0D%0A++snippet%28til_fts%2C+-1%2C+%27b4de2a49c8%27%2C+%278c94a2ed4b%27%2C+%27...%27%2C+60%29+as+snippet%0D%0Afrom%0D%0A++til%0D%0A++join+til_fts+on+til.rowid+%3D+til_fts.rowid%0D%0Awhere%0D%0A++til_fts+match+escape_fts%28%3Aq%29%0D%0A++and+path+%3D+%27asgi_lifespan-test-httpx.md%27%0D%0A&q=pytest

sql select path, snippet(til_fts, -1, 'b4de2a49c8', '8c94a2ed4b', '...', 60) as snippet from til join til_fts on til.rowid = til_fts.rowid where til_fts match escape_fts(:q) and path = 'asgi_lifespan-test-httpx.md' The and path = 'asgi_lifespan-test-httpx.md' bit means we only get back a specific document - but the snippet highlighting is applied to it.

I think the right way to do this is to support multiple optional --cors-origin= pattern values, like you suggested.

I don't want to add a full HTML parser (like BeautifulSoup) as a dependency for this feature. Since the HTML comes from a single, trusted source (GitHub) I could probably handle this using regular expressions.

I'm going to rewrite those <a href="#filtering-tables"> links to <a href="#user-content-filtering-tables"> - but only if a corresponding id="user-content-filtering-tables" element exists.