You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bit of an ambitious refactor proposition. I'm mostly opening this issue to see if there's interest from the community before I and other devs from the community consider getting our hands dirty.
Is your feature request related to a problem? Please describe.
I imagine when this project started, its huge success wasn't anticipated and it seemed ok to have plugins added to the core repo via pull requests. But today, the situation is that in order to even make the first steps with eliza, there's a little barrier to entry in the form of cloning this massive repo, fetching all of the dependencies from every plugin ever integrated, building all the plugins just to be able to see a SBF example that fetches Solana balances. This situation not only hinders the devex but the disk footprint is also huge (9.2GB for the node_modules/ and 1.8GB for the built plugins).
Describe the solution you'd like
It would be great if instead of cloning the repo with all its plugins and all their dependencies eliza would be installed via a dedicated CLI with commands like
# Installs the minimal core elements
$ eliza init [--template template-name]
then plugins could be installed on-demand with
# Installs the plugin and its dependencies
$ eliza add plugin-name
Describe alternatives you've considered
An alternative to this approach today would be to make forks of the repo where everything that isn't used would be deleted. I think doing this at least once would actually be a great first step towards implementing this refacto just to get an idea of what is core, what is necessary plugin for a bare minimum setup and what is potential bloat.
Additional context
As I said in the intro, this issue is mostly to measure the interest for such a solution. First, as a concerned dev because I think this would make the product better, but also as someone who'd be down to rolling up my sleeves and (at least partially) get it done if people think it's a good plan.
The text was updated successfully, but these errors were encountered:
Hello @Mouradif! Welcome to the elizaOS community. Thank you for opening your first issue; we appreciate your contribution. You are now an elizaOS contributor!
This is a bit of an ambitious refactor proposition. I'm mostly opening this issue to see if there's interest from the community before I and other devs from the community consider getting our hands dirty.
Is your feature request related to a problem? Please describe.
I imagine when this project started, its huge success wasn't anticipated and it seemed ok to have plugins added to the core repo via pull requests. But today, the situation is that in order to even make the first steps with eliza, there's a little barrier to entry in the form of cloning this massive repo, fetching all of the dependencies from every plugin ever integrated, building all the plugins just to be able to see a SBF example that fetches Solana balances. This situation not only hinders the devex but the disk footprint is also huge (9.2GB for the
node_modules/
and 1.8GB for the built plugins).Describe the solution you'd like
It would be great if instead of cloning the repo with all its plugins and all their dependencies eliza would be installed via a dedicated CLI with commands like
# Installs the minimal core elements $ eliza init [--template template-name]
then plugins could be installed on-demand with
# Installs the plugin and its dependencies $ eliza add plugin-name
Describe alternatives you've considered
An alternative to this approach today would be to make forks of the repo where everything that isn't used would be deleted. I think doing this at least once would actually be a great first step towards implementing this refacto just to get an idea of what is core, what is necessary plugin for a bare minimum setup and what is potential bloat.
Additional context
As I said in the intro, this issue is mostly to measure the interest for such a solution. First, as a concerned dev because I think this would make the product better, but also as someone who'd be down to rolling up my sleeves and (at least partially) get it done if people think it's a good plan.
The text was updated successfully, but these errors were encountered: