SFSU uses "legacy" method for locating custom Scoop installation
Closed this issue · 5 comments
Describe the bug
sfsu
commands, such as search
and list
, cannot be run without it showing an error, when scoop
is installed at a custom location. e.g. scoop
installed at P:
and not at ~/scoop.
To Reproduce
Steps to reproduce the behavior:
- Install
scoop
at another drive letter other than its default location, i.e. ~/scoop - Install
sfsu
- Run
sfsu list
- See error
Expected behavior
sfsu list
should successfully return with installed packages.
Full Output
> sfsu list
thread 'main' panicked at 'Scoop path does not exist', src\main.rs:51:9
Version [e.g. 1.4.7]
Additional context
I thought this issue would've been fixed by #11.
I'm not a dev, so please excuse me if I'm incorrect.
Hey, sorry for the late response, How have you set the custom directory? I have had scoop set in a custom directory for ages and it has never been an issue for me.
First, I uninstalled scoop
, which was installed at ~/scoop, using the directions given here.
Then, I installed again, but this time to a custom directory as followed (source):
irm get.scoop.sh -outfile 'install.ps1
.\install.ps1 -ScoopDir 'P:\scoops\scoop' -ScoopGlobalDir 'P:\scoops\globalscoops'
And thank you for this utility. I hope sfsu
replaces scoop's original search soon.
Edit: On Windows 11 (21H2)
Edit2: Windows is installed at C:
. P:
is at a separate drive.
Ah, yeah generally the way to change Scoop's install dir is via the SCOOP and SCOOP_GLOBAL environment variables respectively. This is how sfsu detects the install directory, and the Scoop install script detects these as well.
I probably could add support for the arguments passed to the install script, but I'm not sure where I'd start and the environment variable solution is what is mentioned in the docs, and what most people are using. Also implementing another solution for another edge case would add more overhead to startup that I don't really want.
I'd suggest using this as well, don't worry about uninstalling scoop again, but you can just set the environment variables to their respective directories, and everything should work fine.
If for any reaason you can't use the env variable solution, let me know and I'll work on implementing the other way.
Now, I see. I didn't go the route of using environment variables, because the scoop doc says it's a "legacy method" and "not recommended".
Anyhow.. I'll just use the environment variables.
Thanks for the prompt response and keep up the good work!
Edit: Some how, I can't remove the label "bug" for this issue, because obviously this is not a bug.
Huh, honestly didn't realise it was considered "legacy".
I'll see if I can work on supporting the new method.
Edit: Some how, I can't remove the label "bug" for this issue, because obviously this is not a bug.
I believe only maintainers can edit issue labels