Add new DeviceReader constructors

[bruno-f-cruz]

Closes #25

[glopesdev]

@bruno-f-cruz thanks, looks good overall. I have a few questions / comments:

• Would be nice if bf816e2 would be in its own PR so that it gets listed in the release notes. Is it too hard to extract? Doesn't look like the rest of the PR is depending on it.
• What linter are you using? Can you run black on the current repo state? When I run it on my end I'm getting a different result. Maybe we could agree on what tools we use and then add them to pyproject.toml in a separate PR.
• I'm having second thoughts about the use of base_path. I don't like that it is used in different ways depending on which function gets called, so maybe it would be best to get rid of it entirely?

[glopesdev]

base_path is indeed getting clunky, I'm slightly uncomfortable of having different behaviors depending on which function gets called here, so maybe just getting rid of it would be best.

[bruno-f-cruz]

Not sure I follow. The use of base_path is consistent across methods. If provided it will try use it as a root directory where all files are expected to be found. If not provided it will assume either the current working directory (e.g. from_url) or the root of the provided yml (e.g. from_file). Are these two defaults what are raising flags for you? Happy to go with a different one if you want. We can also just throw an error at the level of the DeviceReader class if no path was provided and the user try to use the no-input overload of the register load function.

[glopesdev]

Still looking for a better name:

• from_yaml: may be misleading since the others also ultimately use YAML
• from_schema: maybe a little bit better

[bruno-f-cruz]

from_schema makes me nervous as people might think you should pass the actuall schema file (i.e. .yml). Would from_string be better (ToString is also a thing after all haha)?

[bruno-f-cruz]

@glopesdev lets review #28 and #27 first and then we will handle this one.

[bruno-f-cruz]

@glopesdev I am taking a second look at this and I think we need to mainly decide on a few points:

1. Method's names (currently):
   -from_model(takes a parsed instance of the device schema, ie. Model class)
   -from_str(takes the literal yml file)
   -from_url(takes an URL to a device yml)
   -from_file(takes the file path to a local device yml)
   -from_dataset(takes the path to a "on-standard" container, replaces the current entry point)

2. Are any of the methods redundant? (looking at from_file vs from_str for instance)

3. The fate of base_path. I still think it serves a purpose in the API of the function, but maybe you have a cleaner way in mind.

[CLAassistant]

All committers have signed the CLA.