search

mottosso / be

minimal directory and environment management system for collaborative creative projects
GNU Lesser General Public License v2.1
47 stars 4 forks source link

Windows support #10

Open mottosso opened 9 years ago

mottosso commented 9 years ago

Goal

be is and forever will be as compatible with Windows as any other OS. It's a primary goal. Considering most smaller productions happen on Windows, whereas the larger ones happen on Linux and be applies to both.

However, other platforms have a richer feature set available for the command-line, which in turn can make the experience interacting with be more pleasant.

So a number of options must be considered moving forward on how to build be in such a way that Windows users reap the same benefits as users of other platforms, and that other platforms don't suffer for Windows lack of features.

Alternatives

  1. Make cmd.exe the lowest common denominator. Stick to cmd.exe, limit what can be done using e.g. bash by what can also be done by cmd.exe.
  2. Augment cmd.exe, with something like [clink](), the command-line can gain bash-like features.
  3. Replace cmd.exe, with something like cygwin's bash, for a fully transparent experience (and implementation) of all platforms.

A downside of cygwin is adoption; users won't be able to simply pip install and run, but must first commit to installing a 200mb+ collection of 50+ tools.

Clink solves this, as it merely augments the limited capabilities of cmd.exe.

And finally, cmd.exe is simply too limiting to provide a comfortable experience with be.

An advantage of cygwin however is unified development; anything we build for bash will work across all operating systems, minimising maintenance efforts.

Clink is sort of a middle ground, but we still need to separate subshell implementations.

jedfrechette commented 9 years ago

I'll leave this as a comment here since I'm not sure it should qualify as a bug in be, but is related to alternative 3.

On Windows I typically use Git-bash as my shell, which mostly provides a *nix environment and all of the usual utilities. However, one that is notably absent is mktemp. As a result, _shell.sh fails because it expects it to be available. Googling will turn up a bunch of other projects that fail in the same way inside git-bash, along with the workarounds that they've used.

mottosso commented 9 years ago

Thanks for the note, @jedfrechette.

At the moment, the reason Git Bash doesn't work is tab completion. Even though you may not be interested in tab completion, the way the subshell has been implemented currently is tailored towards it and relies on features of the shell itself not present in Git Bash (the << operators), only "true" bash shells, like MSYS2 and of course bash on Unix.

It can definitely be implemented differently and it's good you mention your use of Git Bash so I know where the userbase is. I simply had not even noticed that it existed prior to working on be.

For the time being, I've been recommending MSYS2 as it's a close equivalent of Git Bash (which looks to be a predecessor, MSYS1) and something I'm using myself during development.