When calling fablib.list_sites(), with fields and/or filter_function arguments, we have some inconsistency in using pretty names like "PTP Capable" and non-pretty names like "ptp_capable":

• Docstrings have examples with pretty names, which do not work.
• The data that comes to fablib from FABRIC services are in non-pretty form.
• The data that is presented to users (in table headers) is in pretty form.
• Jupyter notebook examples use a mix of both forms. Some of them are broken.

Examples from Jupyter notebooks:

• https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/fablib_api/fablib_common/filters.ipynb uses the form filter_function=lambda x: x['RTX6000 Available'] > 3 and x['ConnectX-5 Available'] > 2 , which does not work. It will fail with the message Exception: 'RTX6000 Available', which does not make a lot of sense to users.

• https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/fablib_api/sites_and_resources/filter_sites_by_available_resources.ipynb uses the form fablib.list_sites(filter_function=lambda x: x['nic_connectx_5_available'] > 2 and x['location'][1] < st_louis_lat_long[1], fields=['name','address', 'nic_connectx_5_available']). This works. However the notebook also claims that "calling the list method without setting the fields argument will show all available fields", which is misleading, because list_sites() prints pretty field names. We do not document how/where to find the non-pretty names.

This PR will likely break one set of notebooks. We can probably make both of them work with what would be an ugly workaround hack, but it would be much better if we consistently pick one form and stick with it. That would entail some changes in example notebooks. I don't know if we will be breaking experimenters' notebooks.

I'm not really sure what the problem is here. I don't see any notebooks that use pretty names for searching. I think everything should be non-pretty except when the table is printed.

I think maybe that notebook called "filter.ipynb" is just leftover from development. If it is not linked in the start_here notebook, we can probably just delete it.

Agree with Paul, we should use non_pretty_names for filtering. That's how I have seen it use. We can add more documentation to list_sites() function to make it more clear and also share the calls using which user can know the non-pretty names.

Isn't pretty names the better/simpler UX? With pretty names, fablib users can use the names that appear on table headers. With non-pretty names, they are left to figure it out themselves, or look for more documentation. We should remove that friction.

@sajith - can this be closed?
I thought the consensus was to not use Pretty Names for filtering.

@kthare10 It can be closed, but I also want to be clear that I do not agree with the consensus. :-)

We should be making things easier for users. Being able to filter by the column titles would be easier for users. Having to figure out the special names corresponding to column titles is an extra unnecessary step.