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
Ideally some kind of command in the dapr CLI that can start supporting infrastructure, perhaps like: dapr --runtime-path="./" start-infrastructure
Actual Behavior
If I clean all my systems containers or wish to work on an existing project that already has a .dapr directory, I have no way of starting all the supporting infrastructure.
Steps to Reproduce the Problem
mkdir test
dapr --runtime-path="./" init
# stop and delete all dapr support containers to simulate change
# Scenario 1
dapr --runtime-path="./" init
# (some error about it already existing)
# Scenario 2
dapr --runtime-path="./" ?????
# There's no command to start support containers
Rationale
When I use dapr locally for development, I need to be able to switch between dapr installations. My workstation represents not one, but the potential for unlimited dapr setups. I can't assume that whatever dapr init did the one time I ran it is necessarily going to be forever.
This is why I make use of the --runtime-path option when running the dapr cli.
On a separate note, this also has me curious about upgrade scenarios? If a new version of dapr comes out, how do I upgrade without having to delete and then recreate my .dapr directory?
My whole reason for saving the .dapr directory to a separate path other than my home dir is because it's also where I define all my components. If I'm creating local development setups, I need some way to ship the component definitions.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
In what area(s)?
Not sure?
What version of Dapr?
1.14.1
Expected Behavior
Ideally some kind of command in the dapr CLI that can start supporting infrastructure, perhaps like:
dapr --runtime-path="./" start-infrastructure
Actual Behavior
If I clean all my systems containers or wish to work on an existing project that already has a
.dapr
directory, I have no way of starting all the supporting infrastructure.Steps to Reproduce the Problem
Rationale
When I use dapr locally for development, I need to be able to switch between dapr installations. My workstation represents not one, but the potential for unlimited dapr setups. I can't assume that whatever
dapr
init did the one time I ran it is necessarily going to be forever.This is why I make use of the
--runtime-path
option when running the dapr cli.On a separate note, this also has me curious about upgrade scenarios? If a new version of dapr comes out, how do I upgrade without having to delete and then recreate my
.dapr
directory?My whole reason for saving the
.dapr
directory to a separate path other than my home dir is because it's also where I define all my components. If I'm creating local development setups, I need some way to ship the component definitions.The text was updated successfully, but these errors were encountered: