Feat(wandb): Refactor to be more flexible

[NanoCode012]

Closes #236

Breaking change:

• Swap wandb_run_id -> wandb_name following wandb eng's recommendation Improve documentation and implementation of W&B options #236 (comment) . I have added a warning and backward compatible fix for now.
• RemovesWANDB_DISABLED env if wandb_project passed. This should be the expected behavior.

New feature:

• Now allows any wandb_ config to be passed to env for more flexibility
• More tests!

[winglian]

Does this PR make a major difference since it still points to the same keyword arg here?

[NanoCode012]

Yes!

• it should allow other wandb env without us having to manually add.
• we use run_id and instead of letting wandb automatically generate that. The Engineer said this wasn't good to do. They recommended using name.
• fixed an unexpected issue with conflict of WANDB_DISABLED

Edit: I noticed one edge case from reading their docs on run_id. During resume, it might not continue in the same training and show as new/separate one.

[IgnacioFDM]

Is resume fixed with this? Currently it starts overriding old data (because step begins from 0 after resuming I think).

[NanoCode012]

@IgnacioFDM , yes! That should fix this. Previously, we set run_id which is their internal tracking method. Now, we use name. However, I'm not sure if this will create a new separate run or actually resume. If anyone has the bandwidth, feel free to do a quick test.

[IgnacioFDM]

Just tested it and each time you resume, it creates a new run (with the same name) on wandb.

[NanoCode012]

@tcapelle , thanks for your code snippet a while back and sorry for this late PR. Following your feedback to use wandb_name instead of wandb_run_id, may I ask if you have any idea how to perform a resume in such a case? According to the comment above, it creates a new run instead.

[tcapelle]

Ohh great! Yeah, for resuming, you need the id, so you would need to keep both attributed. Sorry for missing that.

[IgnacioFDM]

I tried setting the WANDB_RUN_ID and it works like it did before this PR: it continues the run, but still leads to wrong data (either new steps don't show up, or they show up but it starts deleting earlier steps).

I think the issue arises from the fact that step (not global_step) resets to 0 when you resume.

[NanoCode012]

Rebased! Updated it to support both wandb_name and wandb_run_id instead of forcing all to name following idea from #824