pybids_db_dir was eliminated without warning, causing migration issues

[pvandyken]

In #296, we consolidated all the database related terms into one single name: pybidsdb_dir. We added a helpful deprecation warning to the old pybids_database_path parameter in generate_inputs, however, we failed to implement any deprecation cycle for the config entry: pybids_db_dir. If you run a workflow with snakebids>=0.9, that entry will not be set.

In all of my workflows, I had a line in my generate_inputs call:

pybids_database_dir=config.get("pybids_db_dir")

After upgrading, snakebids would silently fail to read my database (since it was just getting None to pybids_database_dir). This has stymied me a couple of times already, and I was one of the people behind the rename!

I think it would be really good to have some sort of deprecation, but unfortunately it will be a bit tricky. In the pattern above, we really can't tell if the user is selecting pybids_db_dir out of the config dict. The only way I thought would be to set that variable to some magic value which we can detect. It feels brittle, but at least it would be a temporary measure until we fully deprecate the parameter. And it's arguably better than the current situation.

Any thoughts on this or any better ideas? @tkkuehn @kaitj. If I make a change I'll push it onto the 0.9.x branch so that people have a chance of finding it.

[tkkuehn]

Oh yeah, this is unfortunate. The only symptom of this we can detect is that generate_inputs is called with pybids_database_path=None, which can legitimately happen if there's actually no database. Without a way to inspect the config dict during a snakemake run, I don't think there's a better way to raise a deprecation warning, so I'm onboard to set it to some sentinel value.

[kaitj]

I am also onboard. I think the plan was to deprecate on the next cycle anyways.