Skip to content

Conversation

@kate-goldenring
Copy link
Contributor

No description provided.

@kate-goldenring
Copy link
Contributor Author

It looks like we are using async-trait from core in several of the factors. @rylev is there a motivation around re-exporting from core and importing from there rather than taking a direct dependency on async-trait?

@rylev
Copy link
Collaborator

rylev commented Mar 3, 2025

Nope. I think this a good change.

@kate-goldenring
Copy link
Contributor Author

@itowlson runners are still failing right? Or should i do something to re-kick the tests here?

@itowlson
Copy link
Collaborator

itowlson commented Mar 3, 2025

@kate-goldenring as far as I know runners are still failing

@rylev would you be in favour of making this change in other crates? I can pick that up if so, no need to hold up this PR

@rylev
Copy link
Collaborator

rylev commented Mar 5, 2025

The motivation behind re-exporting async-trait was (I believe) to ensure that consumers of spin-core all could align on the version used by spin-core. Within the spin codebase this isn't a huge issue since everyone should be just using the workspace dependency which ensures everyone is using the same version. This is more helpful with embedders of Spin who cannot rely on the workspace dependency to make sure their versions align.

Given that async-trait is definitely a part of spin-core's public interface, I think it makes sense to use the version of async-trait exposed by spin-core _when the consuming crate is already using spin-core.

@itowlson itowlson merged commit 539cedf into spinframework:main Mar 10, 2025
17 checks passed
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

Successfully merging this pull request may close these issues.

3 participants