Remove `auth` requirement for unless needed

[bryanvaz]

Ran into a "fun" CI brick wall which might require an internal Turso business strategy discussion. No point in submitting a PR if behaviour is intentional.

Problem:

When running test suites in a CI pipeline and trying to load fixtures into a local libsql docker using turso db shell, the CI runner gets hit with the fun message:

You are not logged in, please login with turso auth login before running other commands.

This should also fail if the CI attempted to spin up a turso dev instance.

Personally, I prefer deterministic test suites, which in part means that internet connectivity and remote services should not be part of a test unless those remote services (and/or internet connectivity) are specifically being tested in some way. In theory, there should be no reason to require an auth/api token for local turso/libsql activity.

Proposed Solution

• Remove global auth token check
• Check for auth token only if making remote call to turso services
• If connecting to a non-Turso db via turso db shell without an auth token, warn about lack of auth token, but do not block connection <-- depends on business strategy, see below.

Current Workaround: Set TURSO_API_TOKEN env variable to any non-null value

Rationale

Whether or not this is a bug or an intentional feature should be based on two things:

1. What is the business strategy and purpose of the turso-cli and its relationship to the libsql repo?
2. Should turso-cli support automated, deterministic, offline databases, and offline CI pipelines? (and how should they be supported?)

I've outlined two sides of the strategy this issue could fall into, but obviously there could be other views depending on what the actual business strategy is.

1. turso-cli is primarily for facilitating Turso customers

• turso-cli is a Turso tool meant to support Turso customers to develop, deploy, and manage production Turso databases.
• turso-cli should encourage potential customers through the sales pipeline (i.e. registration, free databases, and eventually a paid subscription)
• Resources should be conserved and focused towards this goal
• Therefore, this is intentional behaviour.
  • To use the turso-cli for local databases without logging in, TURSO_API_TOKEN env variable should be set to any non-null value, however not all features may work as expected.
  • While use of turso-cli with libsql might be possible, it is not guaranteed and not all features may be available

2. turso-cli is the defacto client for libsql, in addition to Turso paid services

• Anyone using sqlite should try using libsql as a drop-in replacement.
• There is an ecosystem around libsql that is fully supported by Turso and its enterprise offerings, however use of Turso is not required in order to leverage the benefits of libsql.
• Using libsql and its ecosystem of tools should be as seamless as working with the sqlite ecosystem.
• All Turso tools should also work with self-hosted/file-only libsql instances (wherever applicable)
• By using Turso tools to help manage your libsql usage, you can also easily transition to Turso managed databases when you are ready to scale-up/scale-out your application.
• Therefore, this is a bug
  • Use of turso-cli and client libraries should not be contingent on having a Turso account

[haaawk]

Thanks for reporting the issue @bryanvaz - 0.95.2 has the fix

[bryanvaz]

Hey Piotr, (@haaawk) I just reviewed the PR. Did you want to include the other side of the command as well, i.e. local dev databases?

❯ turso dev --db-file /tmp/local.db
You are not logged in, please login with turso auth login before running other commands.

Again goes to the strategy of whether people should be using turso-cli or libsql for self-hosted databases for local dev and CI

[haaawk]

Sure -> https://github.com/tursodatabase/turso-cli/pull/882