Linux and macOS support in PowerShell 6

[leonyu]

Not sure if it would break backward compatibility, but PowerShell 6.0 supports Linux and macOS, it would be nice to get it working there, since the core of Scoop is just a JSON-configurable "portable apps" package manager, just so happen most of the main repo tools are Window apps.

I tried running the one-liner in Docker with one of the images here. It fails because the code is using \ for path delimiter, thus not portable. This can be remedied using Join-Path, but it only support 2 parameters, so would probably need to write a utility function for it. Not sure if there are other problems in Linux and macOS.

[gdoenlen]

What benefit would scoop provide over traditional package managers on those platforms? From my understanding scoop doesn't really manage packages/dependencies like a traditional Linux package manager would as most windows applications have their dependencies bundled with them.

[leonyu]

Some developers do not use built-in package manager for their platform because:

• packages could be outdated or of non-desired release version (e.g. Node.js, OpenJDK)
• packages in the package manager repo are installed in non-desired path or directory structure (e.g. Android Studio)
• packages are not compiled/linked with the desired version of the compiler/library

Scoop allows for relatively easy setup of private or personal package management system. In addition, since Scoop is competing with Chocolatey, both are targeting WinOps who often have to dabble in Linux these days (e.g. Azure, Docker), I would say supporting Linux is a boon, assuming cost of maintain support is relatively low.

[leonyu]

I think a lot of it is just dealing with / vs \ for path support.

I can submit a PR converting everything, but it will touch a lot of files. I can

• use /
• use Path-Join
• use some utility method that converts between the two

[deevus]

To be honest I'm totally for cross platform compatibility. If it doesn't mean a complete rewrite I say go for it. The existing buckets won't work on linux obviously (unless maybe scoop could support wine).

The main question I have is how much demand is there for another package manager on linux? And one using powershell at that. It would be unreasonable to expect the current main contributors to pick up the slack for *nix, so it would depend somewhat on how dedicated you are to helping maintain cross platform compatibility (building tests etc), and also creating a default bucket for users to get software from.

/cc @lukesampson

[leonyu]

I don't plan to create buckets for Linux, just to make sure scoop commands works for Linux, end-to-end.

I assume the current test coverage is reasonable, so that can be leveraged for maintenance to make sure everything works in PowerShell Core on Linux. I might add some integration test to be sure.

I have fixed some tests on Linux already earlier in the year (#2153). From casual observation, bulk of the rest seems to be path related issues, which I didn't want to bite on at the time.

[Calinou]

My main usecase for running Scoop on Linux would be to test/maintain buckets. With systems like Flatpak already in place, I don't feel the need for another package manager on Linux.

[rasa]

Since / works in all environments, a PR to convert \s to /s makes sense to me. @r15ch13?

[krokofant]

I use scoop to manage PowerShell modules, would be nice to have official support on macOS to support the same installer.

[Southclaws]

I'm using PowerShell more and more on mac and all the devs I know who use mac really hate brew so I think there's value in a cross-platform installer for software. Would definitely be neat to run the same shell and the same installer across three different operating systems!

[maanur]

Apart from hard-coded path separators, there's a not-so-easy-to-tackle blocker: usage of Robocopy, which is proprietary and Windows-specific. An open-source alternative needs to be picked for Scoop on Linux to happen.

[eMPee584]

We (Free Software Free Knowledge Uni Group Dresden) would also love to see a way to script download / installation of windows portableapps for our https://schulstick.org/ .. @leonyu if you are still interested in this, can you try if you can get the simple version (sed -i 's/\\/\//') to work? I'm not familar with the code base yet and would take a bit of time to get up to speed on this..

[dwettstein]

Currently, I know of the following issues that could prevent scripts from running on Unix:

• Hard-coded path separator -> replace with Join-Path
• References to environment variables written in lowercase -> always use UPPERCASE, e. g. $env:PATH
• Environment variables are named differently, e. g. $env:USERNAME vs. $env:USER -> use .NET variants:
  • [System.IO.Path]::GetTempPath() instead of $env:TEMP
  • [System.Environment]::UserName instead of $env:USERNAME

[viceice]

We at renovate are also like to have basic Linux support for automated updates.

• https://github.com/containerbase/buildpack/issues/25
• https://github.com/renovatebot/renovate/issues/7876

[rasa]

Currently, I know of the following issues that could prevent scripts from running on Unix:

@dwettstein @maanur noted above that there's a dependency on robocopy.exe. See here. Perhaps we replace this with PowerShell 5.1's Move-Item:

Move-Item –Path $from -Destination $to

[chawyehsu]

@rasa robocopy is a significant component of Scoop. It plays a great role in the process of file movements, many operations will trigger file movements. It's not that easy to replace with Move-Item, not only the latter has bad performance, but also it can't keep the file tree structure.

[pratikpc]

@dwettstein could you create PRs for the same?

As long as improved support for Linux/macOS does not cause regressions on Windows, I don't see the harm in doing so.

[rashil2000]

rsync can be used as an alternative to robocopy on *nix systems.

[rashil2000]

@rasa robocopy is a significant component of Scoop. It plays a great role in the process of file movements, many operations will trigger file movements. It's not that easy to replace with Move-Item, not only the latter has bad performance, but also it can't keep the file tree structure.

It's only used in the movedir function. It's a rather small function at the moment, so a condition check for *nix and subsequent use of rsync should be simple enough.

[amreus]

What benefit would scoop provide over traditional package managers on those platforms?

Old topic I know, but I think a Linux port is more relevant than ever.

For some background, I am a long-time Windows user currently using Windows 10 Home. I will not be moving to Windows 11 for many reasons, and I am currently dual-booting Debian stable in order to acclimate before support for Windows 10 ends. I chose Debian stable specifically for the "stability" - I need my computer to work when I need it and I am not interested in possibly breaking my system or maintaining the latest and greatest distribution of the day.

That said, I want to discover and try new software that I am interested in which may be useful.

What benefit would scoop provide over traditional package managers on those platforms?

• New programs take a long time to make it into Debian stable.
• Automate installation and upgrades for programs which are not currently available in my Linux distribution of choice.
• I am not interested in trying to compile every program I want to try.
• I like the "user-space", one directory per app installation over the traditional Unix way of spreading program files over multiple top-level directories. I also like the scoop way over the native deb package format, flatpacks and snaps even if they are similar.
• Following buckets is good for new program discovery.
• The quick installation and removal of programs in user-space.
• There seems to be a lot of "new generation" programs being made using go and rust which are single-file programs and are a good fit for a scoop like installer on Linux.
• Possible to contribute and share manifests. Creating deb packages, snaps and flatpaks seems infinitely more complex.

I am currently using eget to fill some of these gaps.