@karthik2804 you asked me a couple of days ago about something related to this, so I am not sure if you were already working on it - there was nothing in GitHub and I saw you were working on something much cooler - if you did have something under way then feel free to close this.
The experience for running from a subdirectory looks like this:
(Exception: spin doctor where it integrates into an existing "this is the file you're partying on" notification.)
That output is not currently centralised - I thought about making the spin_common function print it, but spin up can't use that function anyway, and it would have required spin_common to depend on terminal, so I passed on that for now. But we can do it if people prefer. I certainly don't much love the internal API (loose booleans, oh the self-loathing) but thought I'd get feedback before I determined how to clean it up.
Also, the way I did it resulted in showing the absolute path (/home/ivan/whatever/spin.toml) rather than the relative path (../spin.toml). The UX here seemed a little tricky - for one or two levels, the relative path is probably more helpful, but for more than that it just turns into a blur (../../../../../spin.toml). For now I went with the absolute path because I had it to hand, but realistically the commonest case is one level down, maybe two, so there's a strong case for doing it the other way. (Indeed, I'm thinking the terror and confusion of ../../../../../spin.toml would actually make it more noticeable that you were hitting some crazy random manifest you didn't intend.)
This PR adds the "run from subdirectory" behaviour to:
build
doctor
registry push
up
watch
We could add it to spin add but I think it might get confusing where the new component's directory got created. We do already allow spin add -f ../.. though, so maybe I'm being overly cautious. Maybe not behaving like other commands is worse from a potential surprise POV.
Fixes #2828.
@karthik2804 you asked me a couple of days ago about something related to this, so I am not sure if you were already working on it - there was nothing in GitHub and I saw you were working on something much cooler - if you did have something under way then feel free to close this.
The experience for running from a subdirectory looks like this:
(Exception:
spin doctor
where it integrates into an existing "this is the file you're partying on" notification.)That output is not currently centralised - I thought about making the
spin_common
function print it, butspin up
can't use that function anyway, and it would have requiredspin_common
to depend onterminal
, so I passed on that for now. But we can do it if people prefer. I certainly don't much love the internal API (loose booleans, oh the self-loathing) but thought I'd get feedback before I determined how to clean it up.Also, the way I did it resulted in showing the absolute path (
/home/ivan/whatever/spin.toml
) rather than the relative path (../spin.toml
). The UX here seemed a little tricky - for one or two levels, the relative path is probably more helpful, but for more than that it just turns into a blur (../../../../../spin.toml). For now I went with the absolute path because I had it to hand, but realistically the commonest case is one level down, maybe two, so there's a strong case for doing it the other way. (Indeed, I'm thinking the terror and confusion of ../../../../../spin.toml would actually make it more noticeable that you were hitting some crazy random manifest you didn't intend.)This PR adds the "run from subdirectory" behaviour to:
We could add it to
spin add
but I think it might get confusing where the new component's directory got created. We do already allowspin add -f ../..
though, so maybe I'm being overly cautious. Maybe not behaving like other commands is worse from a potential surprise POV.