let `attune.open` work with urls

[ddkohler]

My specific attempt was via a file stored on OSF. The following:

instr = attune.open(r"https://osf.io/6s7gk/download")

currently does not work (OSError).

Using requests.get works

instr = attune.Instrument(**requests.get("https://osf.io/6s7gk/download").json())

solution block might be something like:

try:
   [normal path opening stuff]
except OSError as e:
   return requests.get(r"https://osf.io/6s7gk/download").json()

[pcruzparri]

I think that should probably be its own function (i.e. attune.download() or attune.open_from_url()) for clarity. Or, maybe add a keyword like attune.open(url, url=True) to distinguish opening a local file to a downloaded one. Just thinking troubleshooting is a little easier if we separate local from url methods. Thoughts?

[ddkohler]

Thanks for participating @pcruzparri . My inclination is to keep it simple on user end and keep opening in one namespace. For instance, WrightTools.open works with urls and local paths.

Not sure about how much troubleshooting complexity this will introduce. Is there a specific concern you have?

[pcruzparri]

No serious concern. Just best practice for maintenance and modularity, but this specific case is minor. Still, here are some potential reasons to consider.

1. Just did a test for an error (just passed a slightly wrong link) and I get a generic JSONDecodeError. One can look up in the traceback to see it's a requests error, and therefore, and issue with the download, but naming would tell user where just to troubleshoot the file contents or to check file contents and request response.
2. After testing a few times (<10) with downloading the file), now my time to get a response from is about 5 mins and the response is the following json output:

{'message_short': 'Forbidden',
 'message_long': 'You do not have permission to perform this action. If this should not have occurred and the issue persists, please report it to <a href="mailto:support@osf.io">support@osf.io</a>.',
 'code': 403,
 'referrer': None}

This'd probably require different handling of the output, so in my mind better to separate it or give it a name that hints at the potential issues (maybe a little more helpful than going through a tracestack).

Going either way shouldn't have much impact on user nor dev, so no strong opinions on this one.