Allow users to specify a project (don't just default that to "datasette")

[simonw]

Right now every deploy made with this project occurs in a Zeit project called "datasette" - and new deploys over-write the previous https://datasette.simonw.now.sh/

This is bad! Need to figure out a smart way to help users specify the project to be written to.

This is similar to how --service works in datasette publish cloudrun - I ended up making --service a required option there. Maybe --project should be required here?

[simonw]

It looks like the now --name option can do this: https://zeit.co/docs/now-cli#commands/now/unique-options/name

BUT...

I'm a bit confused by project linking: https://zeit.co/docs/now-cli#commands/now/project-linking

[styfle]

Ideally, the user would create a new repository for their project and then import the repo so that deployments are created via git push.

Then there is no need to install or learn the CLI.

See https://vercel.com/docs/git for more info.

[simonw]

My use-case here is a bit different from that - the idea with Datasette is to support people creating one-off deployments for specific databases, so asking them to set up a GitHub account for each one doesn't work (I want my users to be able to work without understanding or thinking about GitHub at all).

I don't want to tell my users "in order to publish your database you need to first create a new repository for it on GitHub" - that doesn't fit the ad-hoc data publishing workflow I'm trying to encourage.

I'm going to use the "name" property of now.json for the moment, and cross my fingers that it doesn't get deprecated and removed! https://zeit.co/docs/configuration#project/name

[simonw]

https://datasette-fixtures.simonw.now.sh was deployed with:

datasette publish now2 ../datasette/fixtures.db --project datasette-fixtures

[simonw]

What happens if you use a project name that someone else is using already? Like https://hugo-hello-friend.now.sh/

$ datasette publish now2 ../datasette/fixtures.db --project hugo-hello-f 
> UPDATE AVAILABLE The latest version of Now CLI is 17.1.1
> Read more about how to update here: https://zeit.co/update-cli
> Changelog: https://github.com/zeit/now-cli/releases/tag/17.1.1
> Deploying /private/var/folders/bl/5x847xbj2yb7xmp7f2tz7l280000gn/T/tmpvpvoizap/datasette-now-v2 under simonw
> Using project hugo-hello-friend
> Synced 1 file (261B) [377ms]
> https://hugo-hello-friend-r1ntou5dr.now.sh [v2] [785ms]
┌ index.py        Ready               [14s]
└── λ index.py (7.3MB) [sfo1]
> Ready! Aliases assigned [16s]
- https://hugo-hello-friend-tau.now.sh
- https://hugo-hello-friend.simonw.now.sh [in clipboard]

That seems reasonable to me.

[simonw]

Posted vercel/vercel#4021 - Please reconsider deprecating "name" in now.json

[styfle]

What happens if you use a project name that someone else is using already?

I think there is some confusion. Project names don't equal domain names. You'll get a projectname.username.now.sh domain automatically but you can add additional domains, either .now.sh suffix or any custom domain. Visit the Domains tab on your project.

I don't want to tell my users "in order to publish your database you need to first create a new repository for it on GitHub" - that doesn't fit the ad-hoc data publishing workflow I'm trying to encourage.

I see, then you can ignore my GitHub comment above.

That being said, consider a user deploys once, then makes a change to their code, and deploys again. Typically they would want to promote one of these deployments to production and assign the production domain, probably the latest. How do you account for assigning production domains? (the git integration handles this when you merge to master, deploys from a PR are considered preview).

[simonw]

Right now I'm running --prod automatically on every deploy with the tool, which I believe means that their latest deployment will always be promoted to "live" for the given --project they provide.

If the user doesn't want to go live straight away they can use the --no-prod option:

datasette publish my.db --project my-project --no-prod

Does that makes sense? I'm not 100% confident I understand the details of how --prod is meant to be used.

[styfle]

Yes that makes sense. It sounds like the datasette default is the opposite for Now CLI.

I think the word "live" here might be the source of confusion though because every deployment is "live" with ZEIT Now. The only distinguishable difference today is --prod will assign production domains.

However, in the near future, there will be another difference. The --prod flag will also apply different environment variables because users will be able to assign different variables to different environments.