This PR adds --doc-dir option. The name could perhaps be better, but the main idea is this option is for cases where you have no doc provider and need to specify an existing document directory.
This removes support for {doc, Dir} in .app.src. The idea is this is more explicit. That said, there still may be a good reason to continue to support that attribute, but what this PR wants to avoid for v7 is people ending up without knowing publishing stale docs to hex.pm
Further, there will be an ex_doc (rebar3_hex_doc) coming to town this weekend, so we can at least say the case for having that attribute in regards to using ex_doc will be gone.
Specifying an alterate doc output dir via a provider should be done within rebar.config (e.g,., edoc_opts), but still, maybe there's a case I'm missing. I would very much like to get this as "right" as possible as the frustrations / problems folks had around docs in rebar3_hex v6 were the most common. Would hate to come up with a solution and then have to turn around and bust the api again because I / we didn't think through all the cases properly.
This PR adds --doc-dir option. The name could perhaps be better, but the main idea is this option is for cases where you have no doc provider and need to specify an existing document directory.
This removes support for
{doc, Dir}in .app.src. The idea is this is more explicit. That said, there still may be a good reason to continue to support that attribute, but what this PR wants to avoid for v7 is people ending up without knowing publishing stale docs to hex.pmFurther, there will be an ex_doc (rebar3_hex_doc) coming to town this weekend, so we can at least say the case for having that attribute in regards to using ex_doc will be gone.
Specifying an alterate doc output dir via a provider should be done within rebar.config (e.g,., edoc_opts), but still, maybe there's a case I'm missing. I would very much like to get this as "right" as possible as the frustrations / problems folks had around docs in rebar3_hex v6 were the most common. Would hate to come up with a solution and then have to turn around and bust the api again because I / we didn't think through all the cases properly.