xtract-sdk 0.0.7a11
A package used for downloading and processing files from multiple habitats.
Requires Python: >=3.6

# Xtract SDK v0.0.7a6

## Login: Creating an XtractClient object

First, we import the XtractClient class from the Xtract SDK

`from xtract_sdk.client import XtractClient`

Here we create an XtractClient object to request tokens from Globus Auth.

`xtr = XtractClient(auth_scopes=[scope_1, ..., scope_n], force_login=False)`

While additional auth scopes may be added with the `auth_scopes` argument, there are a number of 
default scopes automatically requested within the system. These are: 

* **openid**: provides username for identity.
* **search**: interact with Globus Search
* **petrel**: read or write data on Petrel. Not needed if no data going to Petrel.
* **transfer**: needed to crawl the Globus endpoint and transfer metadata to its final location.
* **funcx_scope**: needed to orchestrate the metadata exraction at the given funcX endpoint.

Additional auth scopes can be added with the `auth_scopes` argument.

When true, `force_login` makes you go through the full authorization flow again.

## Defining endpoints: Creating an XtractEndpoint object
Endpoints in Xtract are the computing fabric that enable us to move files and apply extractors to files. To this end, 
an Xtract endpoint is the combination of the following two software endpoints: 
* **Globus endpoints** [required] enable us to access all file system metadata about files stored on an endpoint, and enables us to transfer files between machines for more-efficient processing.
* **FuncX endpoints** [optional] are capable of remotely receiving extraction functions that can be applied to files on the Globus endpoint. Note that the absence of a funcX endpoint on an Xtract endpoint means that a file must be transferred to an endpoint *with* a valid funcX endpoint in able to have its metadata extracted. 

In order to create an Xtract endpoint, we first import the XtractEndpoint class from the Xtract SDK

```
from xtract_sdk.endpoint import XtractEndpoint
```

Here we create two XtractEndpoint objects to be used later in a crawl, etc.
```
xep1 = XtractEndpoint(repo_type='globus',
                      globus_ep_id='aaaa-0000-3333',
                      funcx_ep_id='aaaa-0000-3333',
                      dirs=['str1', 'str2', ..., 'strn'], 
                      grouper='file_is_group',
                      local_mdata_path='/home/user/metadata')

xep2 = XtractEndpoint(repo_type='globus',
                      globus_ep_id='aaaa-0000-3333',
                      dirs=['str1', 'str2', ..., 'strn'], 
                      local_mdata_path='/home/user/metadata',
                      grouper='file_is_group')
```


The arguments are as follow:
* **repo_type**: (str) at this point, only Globus is accepted. Google Drive and others will be made available at a later date. 
* **globus_ep_id**: (uuid str) the Globus endpoint ID.
* **funcx_ep_id**: (uuid str) optional funcX endpoint ID. 
* **dirs**: (list of str) directory paths on Globus endpoint for where the data reside.
* **local_mdata_path** (str) directory path on Globus endpoint for where xtraction metadata should go.
* **grouper**: (str) grouping strategy for files.

## Crawling

`xtr.crawl([xep_1, ..., xep_n])`

Where `[xep_1, ..., xep_n]` is a list of XtractEndpoint objects.

The crawl ID for each endpoint will be stored in the XtractClient object as a list `xtr.crawl_ids`. Furthermore, each endpoint will be stored in the XtractClient object in a dictionary `cid_to_xep_map`, where each crawl id key maps to the corresponding endpoint as a value.

Behind the scenes, this will scan a Globus directory breadth-first (using globus_ls), first extracting physical metadata such as path, size, and extension. Next, since the *grouper* we selected is 'file_is_group', the crawler will simply create `n` single-file groups. 

The crawl is **non-blocking**, and the crawl_id here will be used to execute and monitor downstream extraction processes. 

### Getting Crawl status

`crawl_statuses = xtr.get_crawl_status(crawl_ids=None)`

We can get crawl status, seeing how many groups have been identified in the crawl. If `xtr.crawl()` has already been run, then `xtr.get_crawl_status()` will get the status of the IDs stored in `xtr.crawl_ids`. Otherwise, a list of `crawl_ids` may be given to `xtr.get_crawl_status()`.

This will return a dictionary resembling: 
```
{‘crawl_id’: String,
 ‘status’: String, 
 ‘message’: “OK” if everything is fine otherwise describes error,
 ‘data’: {'bytes_crawled': Integer, ..., 'files_crawled': Integer}}
```

Note that measuring the total files yet to crawl is impossible, as the BFS may not have discovered all files yet, and Globus does not yet have a file counting feature for all directories and subdirectories. I.e., we know when we're done, but we do not know until we get there. 

**Warning:** it currently takes up to 30 seconds for a crawl to start. *Why?* Container warming time. 

### Crawl and wait

For ease of testing, we've implemented a **crawl_and_wait** functionality, which will crawl the given endpoints and then print the crawl status of all given endpoints every two seconds until all have completed crawling. This can be used as follows:

`xtr.crawl_and_wait([xep_1,...,xep_n])`

### Flushing Crawl metadata

`xtr.flush_crawl_metadata(crawl_ids=None, first_n_files=100)`

After running a crawl, we can use `xtr.flush_crawl_metadata()` to return a list of all metadata from the crawl. 

Similarly with `.get_crawl_status()`, if `xtr.crawl()` has already been run, then `xtr.flush_crawl_metadata()` will get the status of the IDs stored in `xtr.crawl_ids`. Otherwise, a list of `crawl_ids` may be given to `xtr.flush_crawl_metadata()`.

Each time metadata is flushed, the number of files for which metadata is returned will be equal to `first_n_files`, and then that metadata will not be able to be flushed again.  

Flushing crawl metadata will return a dictionary resembling:
```
{"crawl_id": String,
 "file_ls": List,
 "num_files": Integer,
 "queue_empty": Boolean}
```

## Xtract-ing

### Registering containers for Xtraction

`xtr.register_containers(endpoint, container_path)`

In order to perform an xtraction, we must have the requisite containers for each extractor that is to be used. After creating client and endpoint instances, containers must be registered for each endpoint, using `.register_containers()` as follows:

```
xtr.register_containers(xep1, container_path='/home/user/containers')
xtr.register_containers(xep2, container_path='/home/user/containers')
```

Where the **container_path** (str) argument should be the path to the xtraction containers on the Globus endpoint.

This can be executed regardless of **crawl** completion status.

### Xtract

`xtr.xtract()`

The **crawl** method must have already been run, and an **xtract**ion will be run for each endpoint that was given to **crawl**. **xtract** will return the HTTP status response code, which should be 200.

### Getting Xtract status

`xtr.get_xtract_status()`

The **xtract** method must have already been run, and this call will return a list of **xtract statuses**, one for each endpoint given to **crawl**.

This will return a dictionary resembling:

```
{'xtract_status': String,
 'xtract_counters': {'cumu_orch_enter': Integer, 
                     'cumu_pulled': Integer, 
                     'cumu_scheduled': Integer, 
                     'cumu_to_schedule': Integer, 
                     'flagged_unknown': Integer, 
                     'fx': {'failed': Integer, 
                            'pending': Integer, 
                            'success': Integer}}
```

## Offload metadata

`xtr.offload_metadata(dest_ep_id, dest_path="", timeout=600, delete_source=False)`

The **offload_metadata** method can be used to transfer files between two endpoints, and is included in this SDK for the purpose of transferring metadata from **xtract**ion. It takes the following arguments:
* **dest_ep_id**: (str) the ID of the endpoint to which the files are being transferred.
* **dest_path**: (optional str) the path on the destination endpoint where the files should go
* **timeout**: (optional int, default 600) how long the transfer should wait until giving up if unsuccessful
* **delete_source**: (optional boolean, default False) set to True if the source files should be deleted after metadata completion

This method will transfer the metadata to a new folder (in the destination path, if supplied) which is named in the convention **YYYY-MM-DD-hh:mm:ss**. Calling the function will return the path to this folder on the destination endpoint.

## Search: coming soon! 

## Downloaders: coming soon!