When you're running a script in an automated environment, you can control wandb with environment variables set before the script runs or within the script.
# This is secret and shouldn't be checked into version control
# Name and notes optional
WANDB_NAME="My first run"
WANDB_NOTES="Smaller learning rate, more regularization."
# Only needed if you don't checkin the wandb/settings file
# If you don't want your script to sync to the cloud
os.environ['WANDB_MODE'] = 'offline'
Use these optional environment variables to do things like set up authentication on remote machines.
If you have automated tests or internal tools that launch runs logging to W&B, create a Service Account on your team settings page. This will allow you to use a service API key for your automated jobs. If you want to attribute service account jobs to a specific user, you can use the WANDB_USERNAME or WANDB_USER_EMAIL environment variables.
Create a service account on your team settings page for automated jobs
This is useful for continuous integration and tools like TravisCI or CircleCI if you're setting up automated unit tests.
Arguments passed to
wandb.inittake precedence over the environment. You could call
wandb.init(dir=os.getenv("WANDB_DIR", my_default_override))if you want to have a default other than the system default when the environment variable isn't set.
wandb offlinesets an environment variable,
WANDB_MODE=offline. This stops any data from syncing from your machine to the remote wandb server. If you have multiple projects, they will all stop syncing logged data to W&B servers.
To quiet the warning messages:
logger = logging.getLogger("wandb")
If you're using a shared machine and another person is a wandb user, it's easy to make sure your runs are always logged to the proper account. Set the WANDB_API_KEY environment variable to authenticate. If you source it in your env, when you log in you'll have the right credentials, or you can set the environment variable from your script.