Closed wereii closed 5 years ago
My guess is this will work if you set 'validate_requests' to false when you create the bravado client. That would be code like this:
SwaggerClient.from_url("https://evekit-market.orbital.enterprises//swagger",
config={'use_models': False, 'validate_responses': False, 'validate_requests': False})
I've had trouble in the past with bravado not properly implementing validation. In this case, however, it looks like some part of my library is sloppy about type conversion. I'll attempt to reproduce.
Thanks for the report!
Thanks for raising this ticket! As a result of debugging, I've found other problems due to changes in pandas and matplotlib. You'll eventually hit those as well so I'll need to release a new notebook (and update many of the other examples as well). I will continue with the current code until I can reproduce your issue (I haven't yet).
That said, another fix is to set compute_date (cell 2) to something earlier than the current day. Two days before the current day should always be safe. One day before the current day can be safe depending on time of day (if you work on this after noon UTC, then the previous day is normally fine). If you set compute_date in this way, then you'll retrieve data from the archive (on Google Cloud Storage) rather than the live server. This will avoid Swagger and will also be much faster.
What you're trying to do should absolutely work against the live server using the current day as long as you backdate market history as you've done. However, it is almost always slower because the live server has to compute the book snapshots on the fly.
I've just pushed an update to Example 13 which should run correctly with the latest pandas and matplotlib. I haven't yet reproduced the issue you saw, although I now suspect it is caused by the latest version of swagger-spec-validator. I'll know shortly.
For now, I suggest you run the example as follows. This will allow you to use recent data without having to rely on swagger:
# In cell 2, set compute date to a recent date
compute_date = datetime.datetime.now(datetime.timezone.utc) - datetime.timedelta(days=2)
compute_date = compute_date.replace(hour=0, minute=0, second=0, microsecond=0)
If you use the version of the example I just uploaded, then no other changes should be required. Note that the list of items in cell 14 will be different because you are using more recent data. Likewise, the types analyzed in the remainder of the example will be probably be different as the most actively traded items these days are probably quite different than two years ago.
Hope this helps!
Still trying to reproduce this but with no luck so far. The only real difference between your environment and mine at this point is:
I do have access to a windows machine so I'll try to reproduce there next. If that doesn't work, I will make some defensive changes which should hopefully prevent the issue in the future.
Sorry for late reply, was busy. Thank you for this fast reply and work!
I tried some debugging for myself, it only happens when I try fetching current date.
dates=[datetime.datetime.now()]
It threw same thing even with this dates=[datetime.datetime.now().replace(hour=0, minute=0, second=0, microsecond=0)]
.
I will now try your new version and report back if anything bad happens. 👌
Finally managed to reproduce this on windows and disabling request validation does indeed fix it. I'm fairly certain the requests are actually correct, but if I can't figure it out I'll check in the version which disables request validation.
Fix committed to head.
Where
Example_13_Detecting_Market_Making, 9th cell (
# Finally, we're ready to start...
)What
Changes
compute_date = datetime.datetime.now()
to get fresh datadate_range = pd.date_range(compute_date - datetime.timedelta(days=30), compute_date - datetime.timedelta(days=5))
shortened the date range by 5 days to not load latest but blank data in next step (it hangs then)Notes