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

Problem compiling external libraries with implementations of DigitalTwinAdapter and MappingClient #46

Closed
ruifelixpereira opened this issue Sep 6, 2023 · 8 comments
Assignees

Comments

@ruifelixpereira
Copy link

Following the documentation for external libraries, I've created 2 crates that implement DigitalTwinAdapter and MappingClient. After running depgen they are added to the generated lib crate. This is my example:

pub use azure_cloud_connector_adapter::azure_cloud_connector_adapter::AzureCloudConnectorAdapter as CloudAdapterImpl;
pub use energy_ibeji_adapter::ibeji_adapter::IbejiAdapter as DigitalTwinAdapterImpl;
pub use energy_mapping_client::in_memory_mock_mapping_client::InMemoryMockMappingClient as MappingClientImpl;

When executing the freyja cargo build I get errors related with having the 2 crates outside the scope. This is an example of the error and of course I am implementing the traits (one in each crate) with all the methods:

$ cargo build
Blocking waiting for file lock on build directory
Compiling energy-ibeji-adapter v0.1.0 (/home/rfp/workbase/dev/digital-twins-base/substation/energy-freyja/energy_ibeji_adapter)
Compiling energy-mapping-client v0.1.0 (/home/rfp/workbase/dev/digital-twins-base/substation/energy-freyja/energy_mapping_client)
Compiling freyja-deps v0.1.0 (/home/rfp/workbase/dev/digital-twins-base/substation/freyja/depgen/__generated)
Compiling freyja v0.1.0 (/home/rfp/workbase/dev/digital-twins-base/substation/freyja/freyja)
error[E0599]: no function or associated item named create_new found for struct freyja_deps::DigitalTwinAdapterImpl in the current scope
--> freyja/src/main.rs:72:46
|
72 | let dt_adapter = DigitalTwinAdapterImpl::create_new().unwrap();
| ^^^^^^^^^^ function or associated item not found in DigitalTwinAdapterImpl
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a use for it:
|
5 + use freyja_contracts::digital_twin_adapter::DigitalTwinAdapter;
|

error[E0599]: no function or associated item named create_new found for struct freyja_deps::MappingClientImpl in the current scope
--> freyja/src/main.rs:73:45
|
73 | let mapping_client = MappingClientImpl::create_new().unwrap();
| ^^^^^^^^^^ function or associated item not found in MappingClientImpl
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a use for it:
|
5 + use freyja_contracts::mapping_client::MappingClient;
|

Any hints of what I might be missing or did you test the implementation of an external library?

Thanks,
Rui

@wilyle
Copy link
Contributor

wilyle commented Sep 6, 2023

Hi Rui, thanks for letting us know about the issue.

We did test with some external adapters, but I'm guessing they weren't sufficiently isolated from the rest of the project so we didn't see the same issue. I'm a bit confused by the error message though, because those traits are imported by main here. So the compiler's suggestion doesn't seem like it would help.

It's possible that #43 will inadvertently fix this issue. That PR is approved and should go in by end of day, so maybe we can try again tomorrow with the new code.

If that doesn't work, I am currently working on a completely different way of handling plugins that should be more streamlined and might reduce integration issues like this. There shouldn't be anything different you need to do with your adapter implementations, but instead of setting environment variables and using the dependency generator you will just need to author a small rust file. I expect that work will be done sometime next week, so regardless of whether this gets resolved beforehand we should verify that your adapters work with the new approach

@wilyle
Copy link
Contributor

wilyle commented Sep 6, 2023

I just merged that PR. The changes should be transparent to what you're trying to do, can you pull the latest changes and try again?

@ruifelixpereira
Copy link
Author

Hi William,

Yes, the imports are there for sure.
Just tested with the merged PR but the error is exactly the same.

@wilyle
Copy link
Contributor

wilyle commented Sep 8, 2023

Ok, we have one more option we can try before I do some more in-depth investigations. I've been working on a different way of handling adapters and have a PR out for that right now (#48 ) . Once this is in I will have you try one more time with some new code. Note that as part of this change you will have to write ~5 lines of rust code and ~10 lines of toml configuration, but the adapter code should not change and you will not need the dependency generation step or the complex environment config.

ETA on that PR is Monday or Tuesday and once it's in I will provide a complete example in our example applications repo that you can use to help with the new code you'll have to write.

@wilyle
Copy link
Contributor

wilyle commented Sep 11, 2023

@ruifelixpereira the new code for the adapter model has been checked in. The documentation was also updated, so please refer to the quickstart and custom adapters guides which will help with using this new model. As previously mentioned this will not require any changes to the adapter code as it replaces the dependency generation and environment config steps by requiring users to write a small rust crate.

You can find partial examples of the code you'll need to write here. You can also look in the eclipse-ibeji/ibeji-example-applications repo for more complete examples which include a template. The code is currently in PR so you can see it in the wilyle/freyja-sample branch. The template and instructions on how to modify it can be found here.

Let me know if this works for you!

@wilyle
Copy link
Contributor

wilyle commented Sep 12, 2023

Note that the PR in the examples repo I mentioned above has been checked in, so you can now find the example in the main branch

@ruifelixpereira
Copy link
Author

Thanks @wilyle, I've just tested the new code for the adapter model and it works like a charm. Overall it becomes more clean to package these adapters externally as well as the concept of the Freyja App.

@wilyle
Copy link
Contributor

wilyle commented Sep 18, 2023

Thank you for the feedback! This is exactly what we were trying to achieve with this new plugin model, so I'm glad this helped solve this issue!

@wilyle wilyle self-assigned this Jan 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants