mosh icon indicating copy to clipboard operation
mosh copied to clipboard

homebrew support

Open higepon opened this issue 3 years ago • 6 comments

https://github.com/lassik/homebrew-lisp/blob/master/Formula/mosh-scheme.rb

higepon avatar Sep 09 '22 11:09 higepon

That formula works, but head doesn't build (brew install --head lassik/lisp/mosh-scheme).

lassik avatar Sep 09 '22 12:09 lassik

Thanks. Yes we're aware of it and working on it.

higepon avatar Sep 10 '22 01:09 higepon

@okuoku I would like to make mosh available in major package systems. homebrew is kinda supported by lassik's formula.

  • What else do we want to support in terms of popularity or install base numbers?
  • What's preventing them to maintain mosh in their package system?
    • Gauche dependency is the one but it becomes a problem only when building head.
    • extlib/Boehm GC

higepon avatar Oct 04 '22 09:10 higepon

Debian is a good one to start with. They are somewhat stringent about their requirements, so if you can get it into Debian you can probably get it accepted elsewhere easily.

What's the status of BSD support?

lassik avatar Oct 04 '22 09:10 lassik

Hmm, I feel it's relatively less important that we have official packages on the systems. We can ./configure && make && make install on the most of systems so users should be able to install it easily.

Maintaining a package is a heavy task; I'm a professional FreeBSD user but maintaining a port on it still takes some time away.

What else do we want to support in terms of popularity or install base numbers?

For me, (N)Mosh was a special Scheme implementation because it allowed real embedded use; we have shipped number of media-arts and applications with hybrid of Scheme and native code using NMosh in 2010s. Now the idea evolved into Yuni and Yuniframe (J: https://zenn.dev/okuoku/articles/5a7a04e75234b3 ) that aims implementation/language agnostic way to do that though.

So, what's your use-case..? In case we don't have any clear purpose, I don't think adding Mosh to foreign package system is proper goal and it'd just takes our support bandwidth..

If you think providing binary package is the important and the first issue to be solved, I second that we should aim Debian. Packaging request was filed in 2013 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631139 but it seems no progress for a while so it'd be better to start new request, I guess.

What's the status of BSD support?

It's CIed regularly on FreeBSD/NetBSD/OpenBSD and since repology reports we also have DragonFly package , I'll add DragonFly later.. On OpenBSD, it lacks some minor features that prevents tests pass. FreeBSD port is available officially and it's maintained by me.

On FreeBSD, a crash #129 is observed when we run super-complex scripts on it. I'm still investigating issue.

okuoku avatar Oct 04 '22 10:10 okuoku

Thank you lassik and okuoku. First of all I didn't do ./configure && make for probably 10 years except for mosh development

  • even though I work for software development company.
  • even though I'm doing heavy machine learning stuff.

What I'm doing instead is brew/apt/pip/conda. So I thought it would be easier for those who has an interest in Scheme or mosh if we support package systems. But as okuoku mentioned if maintaining a package is a heavy task, I definitely would not do that.

So, what's your use-case..? In case we don't have any clear purpose

I think it's just one of scripting languages/implementations. Scheme is not super popular but people are using it and I'm hoping some of them tries mosh.

higepon avatar Oct 04 '22 10:10 higepon