Run a project from a remote repository
Angelmmiguel opened this issue · comments
Is your feature request related to a problem? Please describe.
There are many different ways a project / workers could be stored. Currently, we are allowing only local resources by pointing wws
to a system folder:
wws ./my-folder
However, this restriction introduces an extra step of downloading and configuring the project in the environment. wws
can identify the resources based on the path, extension and protocol, and prepare the environment on behalf of the user.
Describe the solution you'd like
All the examples require you to clone / download workers. Ideally, the demos must be available in a single command:
wws https://github.com/vmware-labs/wasm-workers-server.git
wws
must detect the resource and prepare the environment based on it. For this initial implementation, it will detect links that ends as .git
to process them as git
repositories. I would like to set other specific configurations related to git like:
--git-folder
--git-branch
--git-rev
Describe alternatives you've considered
The current alternative is to ask you to clone the repo in advance. We want to avoid this and simplify the process.
Additional context
The first step to add this feature would be to identify a place to add this logic. wws
goes through the following process every time you run it:
stateDiagram-v2
init: Initialize project
routes: Identify routes
workers: Prepare workers
server: Initialize server
[*] --> init
init --> routes
routes --> workers
workers --> server
server --> [*]
The project initialization requires:
- Load the project
- Install missing dependencies
Currently, the first step is not required as we only support the local filesystem. The second step is done as a separate step (wws runtimes install
). Both steps are part of the same process as the project is not ready until the files are in the local filesystem and the runtimes are installed.
For me, it makes sense we consolidate these two steps into a single crate. For this reason, I will first rename the runtimes-manager
crate into project
to highlight the new scope.
Thanks @Angelmmiguel! I agree with the assessment of the current situation.
For me, it makes sense we consolidate these two steps into a single crate. For this reason, I will first rename the runtimes-manager crate into project to highlight the new scope.
I agree in consolidating both steps in one crate. I like the new crate name, I think it is descriptive. Another alternative name could be wws-worker-initializer
, which is more verbose. I think we can go with wws-project
though.