edit: Probably a good time to note we have already been experimenting with using notebooks as build scripts (after chatting with some of the Netflix folk who love that notebooks provide an immutable record of inputs and outputs, a bit like bash -x).
Having a single config file is interesting and as you guessed has been discussed a few times already. I think to discuss this topic we need to do it in some context. In what kinds of situations would you want to have a single config file? What was the build up to the situation where you thought “damn, I wish I had a single yaml file here!”?
When I give talks about Binder, I usually say something to the effect of “launching a binder is the reward you receive for following best software practices”. So my two cents are yes I agree, having a single config file would be easier in some regards, but I do think it detracts from the sentiment of the project meeting some software standard and doing so in a way that is familiar to the community the software is embedded in.
That is to say, I know what a requirements.txt file does if I don’t know about Binder, I probably don’t know what a binder.yaml file does.
Binder already prioritises what it looks for when deciding what config files to use. At the risk of yet-another package type, Binder could support a single config file, perhaps considered just after the Dockerfile; there’d be no need to stop supporting any of the other files, it would just complicate things on the Binder side, and make the repo a little less accessible to folk reading it and seeing an unfamiliar binder.yaml
If someone really wanted a binder.yaml file in the meantime, I guess they could write a parser and run it from postBuild? (Or does postbuild block you from apt-get? I forget).
Yes, they do in repo2docker… apt.txt is consumed, then later postBuild is. I’m just not sure if the permissions used for the apt.txt install have been de-escalated by the time the build step gets to postBuild?