-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken links for dependencies belonging to organizations #1975
Comments
@garazdawi this may be related to the conversation we had earlier this week. If we could store in the application the "documentation_url", then it could be used here too? |
The configuration would have to live somewhere like that, so the app file seems like a reasonable place. I discuss it with the team next week and see what they say. If nothing else we can use an application parameter as the place to put it for this and errors. |
If this can't be fixed short term, I'd love to have some decent workaround. I know I can use the But I don't know any way I can read my deps, and iterate on the ones that belong to organizations so that I can provide the correct address. I wouldn't like to hardcode the list of organization dependencies. The I appreciate suggestions on how to achieve that. |
You may be able to read the mix.lock and get all relevant information there. I guess we could also change ExDoc to look at the dependencies options and figure out private Hex repos. We could also allow :deps to be a function, so it is all programmatically. |
I believe it would be great to have it alongside |
I noticed that ex_doc generates wrong links for private packages belonging to organizations.
For example, if I have package linking to module
Foo
, which belongs to the package:foo
, and:foo
belongs to the organizationmy-org
the automatic link will be hexdocs.pm/foo/Foo instead of my-org.hexdocs.pm/foo/Foo. Naturally, this link will be broken.I traced the link generation to here:
ex_doc/lib/mix/tasks/docs.ex
Lines 534 to 539 in d8146c3
As you can see, it doesn't consider whether the package belongs to an organization or not.
I tried to fix it, but didn't find any API to find to which organization a package belongs to.
@wojtekmach suggested usings the
:deps
option forex_doc
to point the correct dependency documentation urls. While this works, it's a big burden to maintain, and I think this could be solved in a simple and more correct way at ex_doc.The text was updated successfully, but these errors were encountered: