You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per the manual section on version ordering, the macos variant is a
package version greater than the linux one - so solvers are expected
to pick libwasmtime.0.22.0+macos-x86_64.
But I guess, authors of packages like this expect the solver to filter
out unavailable packages before it is even considered for solving. So,
on say macos, the solver is supposed to see,
This is a problem for package managers that dont wish solvers to do
this kind of filtering. esy, for instance, wants the solution to
contain all platform variants of the package, so that during the
fetch/installation phase of the package, the package manager that
decide which subset of the transitive closure is relevant for the
user.
For this reason, I like how eio_main is packaged instead.
"eio_linux"
{= version & os = "linux" &
(os-distribution != "centos" | os-version > "7")}
"eio_posix" {= version & os != "win32"}
"eio_windows" {= version & os = "win32"}
Here, the package manager has the option to ignore the filter during
solver phase and apply them in the installation phase.
Can the eio approach be enforced on the repository?
The text was updated successfully, but these errors were encountered:
I noticed
libwasmtime
encodes the platform information in theversion string
As per the manual section on version ordering, the macos variant is a
package version greater than the linux one - so solvers are expected
to pick
libwasmtime.0.22.0+macos-x86_64
.But I guess, authors of packages like this expect the solver to filter
out unavailable packages before it is even considered for solving. So,
on say macos, the solver is supposed to see,
This is a problem for package managers that dont wish solvers to do
this kind of filtering.
esy
, for instance, wants the solution tocontain all platform variants of the package, so that during the
fetch/installation phase of the package, the package manager that
decide which subset of the transitive closure is relevant for the
user.
For this reason, I like how
eio_main
is packaged instead.Here, the package manager has the option to ignore the filter during
solver phase and apply them in the installation phase.
Can the
eio
approach be enforced on the repository?The text was updated successfully, but these errors were encountered: