Gigantum automates the versioning and containerization necessary to make your work reproducible, transparent, and portable. These type of features are best done in the context of an identity so that sharing and collaboration are robust and transparent. When you use the Client you also get access to Gigantum Cloud for syncing and storing Project data. This requires authentication.
We currently only support Gigantum accounts, but future work may allow for other logins (e.g. Github, Twitter). Future work may also allow for using Gigantum locally before creating an account and then later associating your work with an account via your email address, but this capability is not currently supported.
LabBooks have been renamed to Projects. As we continued to get feedback from more users, it became clear that many people already attributed the term "Lab Book" to various existing things and often found it either confusing or off-putting. We chose the term Project because it is provided a generic, yet clear description. While no longer called LabBooks, Gigantum Projects still encapsulate everything you do, including your data, code, and compute environment.
When working inside a Gigantum Project it's best practice to organize your code inside the
code directory, your input data inside the
input directory, and your output data inside the
Some users prefer to use relative paths so that even if they export or run outside Gigantum things work. An example of this would be running a notebook that is stored in the code directory that references the file "my_data.txt" that is stored in the input directory. In your code, you would set the path to be:
my_data_file_path = "../input/my_data.txt"
If you don't like working with relative paths, the absolute path to these directories is always available when working in a Project from the environment variables
LB_OUTPUT. In Python, doing the same thing would be accomplished by:
import os input_dir = os.environ['LB_INPUT'] my_data_file_path = os.path.join(input_dir, 'my_data.txt)