Skip to content
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

Open
v0idpwn opened this issue Dec 6, 2024 · 5 comments
Open

Broken links for dependencies belonging to organizations #1975

v0idpwn opened this issue Dec 6, 2024 · 5 comments

Comments

@v0idpwn
Copy link

v0idpwn commented Dec 6, 2024

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 organization my-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:

defp get_deps do
for {key, _} <- Mix.Project.deps_paths(),
_ = Application.load(key),
vsn = Application.spec(key, :vsn) do
{key, "https://hexdocs.pm/#{key}/#{vsn}/"}
end

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 for ex_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.

@josevalim
Copy link
Member

@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?

@garazdawi
Copy link
Contributor

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.

@v0idpwn
Copy link
Author

v0idpwn commented Dec 7, 2024

If this can't be fixed short term, I'd love to have some decent workaround. I know I can use the :deps option to set the address of package docs.

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 deps() function isn't enough as it doesn't include dependencies of dependencies.

I appreciate suggestions on how to achieve that.

@josevalim
Copy link
Member

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.

@Wigny
Copy link

Wigny commented Dec 10, 2024

store in the application the "documentation_url"

I believe it would be great to have it alongside source_url and homepage_url so maybe projects like ElixirLS could also make use of it to provide link highlights to private docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants