Closed mark-todd closed 2 years ago
Why would it be exceptionally useful if you could change keys at runtime? Why would one want to do that?
So in my particular use case we're building a frontend on top of pybliometrics. This means we need the user to be able to supply their api keys in this frontend as opposed to using the pybliometrics "input" style interface. Other use cases would include things like web apis built on top of pybliometrics, where the user provides their api keys to the website and may not have access to the config file. In both of these cases the API keys must be supplied at the point of sending the request, hence the keys must be changed at runtime.
This is a very interesting use case! I'd love to see your project work (and to see the project in action, of course).
The big problem is that Elsevier has never provided me with an InstToken, despite my many emails. I gave up the hope that they are somehow supporting me, despite the many users that access Scopus through pybliometrics -_-
Maybe a workaround is to provide key and InstToken in the class itself. These values would then be used with priority, instead of those supplied in the config. I guess this could make the web app working, right?
This is a very interesting use case! I'd love to see your project work (and to see the project in action, of course).
Sure! The project is still a work in progress, although should be ready for first release quite soon! It's available here if you want to check it out: https://github.com/dreamingspires/matchmaker.
The big problem is that Elsevier has never provided me with an InstToken, despite my many emails. I gave up the hope that they are somehow supporting me, despite the many users that access Scopus through pybliometrics -_-
Sorry to hear that about the institution token - was it an issue with use case?
Maybe a workaround is to provide key and InstToken in the class itself. These values would then be used with priority, instead of those supplied in the config. I guess this could make the web app working, right?
Yes providing the key and InstToken in the class itself would be ideal - if the Base class I suppose had the option to directly add an institution token and api key that would do the job. I can see it already offers a "key" option - are you saying the token would need to be added to support this?
That's an interesting project you're developing there! Together with another colleague I develop https://sosia.rtfd.io/, which also attempts to find researcher matches - but not for collaborating. We're interested in control groups for Diff-in-Diff analyses.
I'm working on allowing to put both key and InstToken in the class call, e.g. ScopusSearch(..., key=KKK, insttoken=TTT
). The only part that's left is to use these parameters to override the entries in the config.ini.
Turns out this was much easier then I thought.
You can now provide a key via apikey=...
and/or an InstToken via insttoken=...
to any class. This will always override the key/token selected from the configuration file.
Feature Request:
I wish to have the API keys and Institution Tokens be alterable at runtime. I know the documentation explicitly states that pybliometrics does not support this (https://pybliometrics.readthedocs.io/en/stable/configuration.html#runtime), but this is something that would be exceptionally useful.
In my above example on first run the scopus search would be run on the current values in the config file, but then on the second run it would be run on the values supplied in the first run. You can see how this might be problematic - the api keys pybliometrics is using are always one step behind those supplied.
Solution:
If the ScopusSearch in my above example were to take the api keys and tokens from the config file at the point of search, this issue would disappear, as then the create_config line would overwrite the file, and the ScopusSearch line would use the overwritten file. This does mean that pybliometrics would have to check the config file more frequently, but given the config file's small size this would be a negligible performance difference.
Thanks , Mark