search

anchore / binny

Manage a directory of binaries without a package manager
Apache License 2.0
21 stars 1 forks source link

Windows compat tasks #20

Closed willmurphyscode closed 5 months ago

willmurphyscode commented 5 months ago

This is a step towards supporting windows (see #17).

The main goal of this branch is to make the Taskfile stop depending on shell core utils to define variables, for example go list ./... | grep -v {{ .OWNER }}/{{ .PROJECT }}/test | tr '\n' ' ' will fail on Windows because grep and tr are not guaranteed to be on PATH.

Since Python will be available, this branch experiments with python, either in separate files or inline, to perform this work. Requiring Python as a dev dependency seems reasonable, since Python is very widely used. The other choice is maintaining parallel sets of commands in sh and powershell, but I think contributors are much more likely to be comfortable in Python than powershell. In other words, requiring contributors to install Python seems less onerous than requiring them to learn powershell. Additionally, I've done some experiments in powershell, and a lot of things that are very quick one-liners in sh, (e.g. <something> | grep -v <something-else> or test -f <some-file>) are pretty lengthy powershell invocations.

willmurphyscode commented 5 months ago

@anchore/tools what do you all think about the approach here, before I spend a bunch more time going further in this direction. Namely:

  1. Do we think that replacing some real simple shell invocations with a little Python so that they're portable is the right approach?
  2. Do we feel like having some if runtime.GOOS == "windows" { t.Skip( <some reason >) } is an ok intermediate state to be in? I'd like to get CI running Windows unit tests soon, with a small, known set of skipped tests that we can work on.
  3. Do we think that having things like got = strings.Replace(got, string(os.PathSeparator), "/") before test assertions is reasonable? Basically then the test want is written with unix-style paths, and we just do a replace before comparison?

If we think this is reasonable, I'll take approaches like these forward until we can turn on unit tests in CI for binny, but there will be a lot more work like this, so I wanted input on the direction before doing that, in case someone has a better idea or an objection to one of these approaches.