Phoenix support

[tomodachi94]

Requested feature.

Phoenix docs: https://phoenix.madefor.cc

[tomodachi94]

This probably won't be as trivial as #12, but it shouldn't be too difficult.

Maybe we should create a submodule that contains some CraftOS functions rewritten for Phoenix if the port is extremely complex.

[tomodachi94]

Looking into documentation for libcraftos, looks like compatibility should be easy (maybe even as simple as Recrafed was!)

[tomodachi94]

I think we should outsource library compat code to a separate submodule and have all libraries get called from there.

[tomodachi94]

We should probably also integrate with Phoenix's logger. We should introduce a logging function in unicorn.util that uses phoenix logger (or error and print on non-Phoenix systems).

[MCJack123]

Looking into documentation for libcraftos, looks like compatibility should be easy (maybe even as simple as Recrafed was!)

Note that libcraftos is currently incomplete, so you won't be able to test it out yet. Other than that, most CraftOS APIs can be loaded with just require("craftos.*"), similarly to Recrafted's require("rc.*"). One thing to watch out for is the fact that coroutine.yield() is no longer equivalent to os.pullEventRaw()/os.pullEvent(), so if you ever use that then you'll need to fix that to use libcraftos. There's probably a few other compatibility issues with certain functions, but I haven't had the time to fully map that all out yet.

Also, you might want to consider adding an architecture field to make sure you don't end up installing packages for the wrong OS.

[tomodachi94]

Note that libcraftos is currently incomplete, so you won't be able to test it out yet. Other than that, most CraftOS APIs can be loaded with just require("craftos.*"), similarly to Recrafted's require("rc.*"). One thing to watch out for is the fact that coroutine.yield() is no longer equivalent to os.pullEventRaw()/os.pullEvent(), so if you ever use that then you'll need to fix that to use libcraftos. There's probably a few other compatibility issues with certain functions, but I haven't had the time to fully map that all out yet.

Noted, thank you!

Also, you might want to consider adding an architecture field to make sure you don't end up installing packages for the wrong OS.

This is a good idea, but why would this be better than an if-block in the package table? For example,

package.name = "some-phoenix-only-package"
package.pkgType = "com.github"
-- yada yada, other package stuff here --
if not _HOST:find("Phoenix") then
    error("This package is only compatible with Phoenix.")
end

return package -- error will prevent code from continuing if non-Phoenix

cc @MCJack123

[MCJack123]

This is a good idea, but why would this be better than an if-block in the package table? For example,

package.name = "some-phoenix-only-package"
package.pkgType = "com.github"
-- yada yada, other package stuff here --
if not _HOST:find("Phoenix") then
    error("This package is only compatible with Phoenix.")
end

return package -- error will prevent code from continuing if non-Phoenix

The benefit comes at a package listing level - you can hide packages that you know aren't compatible with the current architecture without having to throw any errors while downloading/installing.

Also, Phoenix doesn't have any _HOST variable. In fact, by itself it's pretty difficult to distinguish from a normal Lua enviroment - you could only compare it by checking for things that CraftOS (or Recrafted) has or lacks in the Lua standard library (or check for CraftOS-specific APIs).

[tomodachi94]

Good point. Tracked your request at #16.

cc @MCJack123

[tomodachi94]

@MCJack123 what are your thoughts on having a fake package for packages that only work on a specific platform?

Like this:

-- unicornpkg package table
local package = {}
package.rel = {}
package.rel.depends = {
    "platform-phoenix", -- only proceeds to install if package `platform-phoenix` is installed. This package would be installed by the installer.
    "some-other-package"
}
return package

This has the bonus of being able to show/hide packages based on your current platform (but unicorntool/hoof, the reference CLIs, don't do this).

[MCJack123]

That makes sense, but it does mean that it would allow installing packages without a platform dependency would make it unable to determine compatibility... though any architecture packages already do the same thing, just a bit more explicitly.

You'll also need to make sure that package managers won't try to search for the platform packages when questioned, and won't freak out when they can't find them. This should already be covered for packages that may require other packages in external, not installed repos.

In the end, this does just end up moving the responsibility of writing the architecture required to a different part of the script. IMO this makes the architecture of a package and the use of the platform dependency less clear at a glance, but I assume it also helps the implementation of the package manager more.