PULL_LATEST_SCHEDULE config option?

A very common question throughout all nfl projects is, “why can’t i see the next seasons schedule??”.*

A way to eliminate this is to just have nflgame provide the latest schedule given a flag PULL_LATEST_SCHEDULE. This would allow new users to query future seasons games without manually running update_sched.py --year 2018.

I suspect this was done to prevent accident abuse of the nfl.com json stream, so some planning/research is needed to make sure this wont set off any red flags for nfl.com.

[mickeelm]

So, thanks for all the feedback and a great thread - and thanks a lot for the kind words regarding the scheduling code. I hope that we can rely on it and that the NFL doesn’t get any ideas. There are lots of stuff that you guys’ve written here and I’m not gonna qoute all and respond to it so here’s a sum up:

Regarding run mode/background mode

I’ll create a branch on my fork for this, experiment a bit. We’ll see what happens. When I’m looking at how I’m gonna use this, like my vision for it, a systemd-service that updates the data and just keeps running and running will suit my setup best. I think it’s worth to point out that I’m gonna run nflgame on a 24/7 remote server, not a local computer.

Just to try and clarify what I mean (so answering your comment about live data @ochawkeye) is that I’d like the background process to update during live games (and update schedules, and players, all with “smart” rules on when to get stuff and when not to. Like, in may and june the service will just be idling, waiting for hall of fame week) and save this data (as json, in a database, somewhere). So like, if a game has started and I do this an hour into the game

>>> ìmport nflgame

nothing happens except the library being imported. No external calls - because these are already made, and are continously being made, by the background process, because the background process knows that a game is being played and now is the time to do it. Meaning, that you will have access to the latest live data at all times - just that this is being made by another process and you won’t see the output of it. But once you start querying, you will get the latest.

I’m not saying that it is better though, just that it’s gonna fit my purposes better 😄 Or, this is how my current application has been working (it uses the now deprecated score strip so that’s why my interest in nflgame is very high right now). So, I’ll do this on my fork anyway and we’ll se where to go from there, if anything will be synced back here.

Getting future schedule logic

Right, I think that I might have been unclear here.

• First of all, I agree with you both that we just check PRE0 and if that doesn’t exist, abort. If it exists, check the others (not POST though, those will not be fully populated before REG17 is concluded anyway. I mean they COULD be but probably not).
• Seems like we’ve all agreed on that when we do have all schedules, we won’t check for updates until we are actually in that week. E.g. Derek’s “Each time CURRENT_WEEK changes we simply grab the next week.”

So I was probably unclear regarding “filling holes” in the schedule.

This is where we need to be careful. Say it’s REG1 and I’m developing a short script. (Assume my schedule is good for PRE0-PRE4). Every day I execute my script (with import nflgame at the top) am I attempting to fetch all 17 weeks that appear in REG1-REG17? Probably not a big deal, just clarifying

This is not what I meant, sorry for being unclear. I also changed my mind a bit to make it even more unclear. Summed up, I want this functionality, when update schedule is run:

• Check which schedules we have in schedule.json for the current season.
• If none, check if PRE0 exists and so on, like said earlier.
• If we have some schedules for the season but not all, like we’re good with PRE0-PRE4 but nothing in REG - get REG1-REG17 (e.g. try to get all missing schedules for this season) and if not part of the missing schedules, the current week.
• If we have all schedules, only check the current week. (So, if we were in the previous scenario last time update schedule was run, we got REG1-REG17 that time and we already had PRE0-PRE4 prior, we’ll be in this next state now. E.g. we will not be getting all schedules again, only the current week).
• During the period 1st of march to monday morning (when the late games should have ended) after week 17’s games which are all on the sunday week 17, “all schedules” means PRE0-PRE4 and REG1-REG17. Not the postseason.
• The morning after regular season is concluded, “all schedules” also includes the postseason.

One last thing

Maybe worth investigating if a comparison to the schedule.json stored in the repo is newer than the local copy and pulling that one instead. Just brainstorming…

Was going to suggest exactly that before 😃 Don’t know how it would be done but if we have good routines on keeping player, schedule and game data updated in the repo it’s of course a good thing if as many users as possible can pull these changes asap, essentially limiting a lot of traffic to NFL.com.

[derek-adair]

Boy oh boy it makes me happy to see this conversation!

Let me be clear that I would not want any changes to be made that would break things or slow them down. Fetching the whole season every import does seem silly. @mickeelm has the right idea. HOWEVER, i think we can possibly minimize requests sent further by;

1. assume that if PRE0 is the rest will be as well. Same with REG/POST season. This will, i beleive, populate the json files as the season transitions to at least have data for future games.
2. Each time CURRENT_WEEK changes we simply grab the next week.

The consequence would be slightly less accurate games in the future. Its very possible this is being to cautius w/ the nfl data stream, but its probably better safe than sorry.

I’m probably being shortsighted here, but I’m just not grasping what a constantly running .run() would buy me that a Windows scheduled task or Linux cron job can’t.

This is another thing that relates to us insulating the project from low-level requests and makes it easier to use. Really nothing more. Its a seriously minor usability win, but these script kiddies can’t open the damn source code and read Andrew’s AMAZING comments.