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

Support imports from other crates #34

Open
shadaj opened this issue Jul 23, 2021 · 3 comments
Open

Support imports from other crates #34

shadaj opened this issue Jul 23, 2021 · 3 comments
Labels
bug Something isn't working

Comments

@shadaj
Copy link
Member

shadaj commented Jul 23, 2021

When we add support for wildcards, this can be handled similarly by having a fallback that attempts to look up the first symbol in a path by resolving it to a crate declared in some Diplomat config.

@Manishearth
Copy link
Contributor

I don't think we need to have support for wildcards for Diplomat imports?

Non-diplomat imports, definitely.

@sffc
Copy link
Contributor

sffc commented Aug 3, 2021

We can start throwing errors after we add annotated imports (#31). Cross-crate imports could be a future enhancement.

@sffc sffc added the bug Something isn't working label Aug 3, 2021
@Manishearth
Copy link
Contributor

The way this would probably work is that diplomat-tool can dump json specs for various crates, and these specs can be fed back to diplomat-tool which will add the json specs to its import graph.

We should not be trying to automate this further: trying to magically run diplomat on the entire dependency tree will have the same problems cbindgen does. For a given application, whoever is running diplomat-tool will already know where the diplomat-using crates are and they can easily sequence it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants