Closed buzden closed 11 months ago
Thanks for reporting this. About the expected behavior: The first option is not viable, because some applications only work properly if the correct version is invoked for the current pack environment. The most obvious example for this is idris2-lsp. The second option would mean that we put applications on the PATH
and remove them as well depending on the current pack environment. Again, I'm not sure how to best do this.
So, the best option would be the third one: Improve the error messages, probably by including the necessary steps to make the application available again.
I don't have much time to do non-work stuff at the moment, so contributions here would be highly welcome.
Steps to reproduce
Consider an application project
an-application
which is not in a pack collection with a localpack.toml
declaring[custom.all.an-application]
in it. Consider I invokepack install-app an-application
from the project's folder. Here CLI commandan-application
works perfectly.Now, go to the folder which does not have the described above
pack.toml
and try to invokean-application
from the command line.Expected behaviour
I would expect any of the following behaviours:
an-application
application being run with what was installed the last time, ORan-application
command not being found inPATH
, ORan-application
is not found in the current context.Observed behaviour
The current behaviour is falling with
Analysis
The reason for this behaviour is that inside the
an-application
commandpack app-path an-application
is being called, which falls withbut this is not captured and this output is tried to be used as an application name to be run. Moreover, is seems that
APPLICATION
variable should be put in quotes during the call on the line 6.